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© Redirection of calls by a communication terminal. 



© A telecommunication protocol message that al- 
lows redirection of a call received by a first tele- 
phone station set to a second telephone station set 
or other terminal equipment by the first telephone 
station set transmitting the redirect message to a 
telecommunication system connected to the first 
telephone station set. The redirect message includes 
the identification of the user of the first telephone 
station set as well as the telephone number of the 
second telephone station set or terminal equipment. 
The telecommunication switching system is respon- 
^ sive to the redirect message to reroute a call to the 
0> second telephone set. The redirect message allows 
the first station set to transmit only one message to 
f "" > the telecommunication switching system to accom- 
O pfish the functions of rerouting the call. In addition, 
the redirect message gives a BRI (basic rate inter- 
face) station set the capability of automatically for- 
O warding certain types of calls. Since a call setup ' 
f\ message includes the telephone number of the origi- 
LU nating station set, the BRI station set can be pro- 



grammed to transfer calls to different station sets 
based on the originating station number. In addition, 
with the proliferation of facsimile machines (often 
referred to as FAXs), there is a problem in coordinat- 
ing an individual's telephone number with the in- 
dividual's FAX number by a person wishing to send 
a FAX. Using the redirect message, the BRI station 
set can.be programmed to examine the bearer capa- 
bility information encoded as an Information Ele- 
ment, IE, in the setup message to determine the 
type of call that is being set up. If a digital data call 
is being set up, the BRI station set then examines 
the higher layer capability IE in the setup message 
to determine whether or not it is a FAX message. If it 
is a FAX message, the BRI station set will automati- 
cally forward the call to the FAX designated by the 
user of the BRI station set. Further, the station set 
will display a message indicating that a FAX mes- 
sage had been forwarded. Using this technique it is 
only necessary to know a person's telephone num- 
ber in order to send a FAX to that person. 
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Technical Field 

This invention relates to telecommunication 
switching systems and, in particular, to the re- 
routing of a call to one telecommunication terminal 
from another telecommunication terminal. 

Background of the Invention 

Many telecommunication customer features re- 
quire the function of being able to route a call 
intended for one telecommunication terminal to an- 
other telecommunication terminal without human 
interaction. To illustrate this need consider "send 
all calls" and "call coverage" features that are 
standard on most telecommunications systems 
such as the AT&T Definity® Business Communica- 
tions Systems. The "send all calls" feature op- 
erates by rerouting any call intended for a first 
telephone station set to a second telephone station 
set. There are two variations of the "send all calls" 
feature. The first variation is where the user of the 
first station set manually designates the telephone 
number of the second telephone station set by 
performing certain operations on the first telephone 
station set. The second variation of the "send all 
calls" feature is where the telephone number of the 
second station set is administered by the system 
administrator of the telecommunication switching 
system. The "call coverage" feature is similar to 
the "send all calls" with the exception that the "call 
coverage" feature is utilized in what is normally 
called the "boss-secretary" relationship. The "call 
coverage" normally involves a number of station 
sets in a call coverage group. Each station set in 
the call coverage group can receive a rerouted call 
from the intended telephone station set (also re- 
ferred to as the covered station set). Covering 
telephone station sets are arranged in a hierarchy 
for each telephone station set being covered with 
the call being attempted to be rerouted starting at 
the top of the hierarchy. The purpose of the hierar- 
chy is to* assure that the rerouted telephone call is 
answered by the person having the greatest knowl- 
edge of how to handle the call. 

Prior art systems have implemented these fea- * 
tures in one of two ways. The first method is to 
have the central processor controlling the telecom- 
munications switching system maintain in memory 
information pertaining to telephone station sets in- 
voking these features and the covering telephone 
station sets. This method is disclosed in U.S. Pat- 
ents 4,682,354 and 4,790,004. For example/for the 
"send all calls" feature, the central processor is 
responsive to the user of a telephone station set 
actuating a button on the telephone station set to 
record in the memory of the central processor the 
actuation of the "send all calls" feature. Each time 



a call is directed to a telephone station set, the 
central processor checks a record memory to de- 
termine whether or not the "send all calls" feature 
has been activated for that particular station set. If 
5 the "send all calls" feature has been activated, the 
central processor obtains the identity of the cover- 
ing station set and routes the call to that station 
set. The identity of the covering station set was 
either entered by the user of the covered station 

io set or by the system administrator. The "call cov- 
erage" feature is executed in a similar manner, but 
the central processor has to maintain information in 
memory concerning the call coverage groups. In 
addition, it is important that the central processor 

75 identify for the covering station set the telephone 
number of the covered telephone station set or the 
name of the user of the covered station set- 
Other prior art telecommunication switching 
systems have provided for the routing of telephone 

20 calls by having the covered telephone station set 
accept the call, place a second call to the covering 
telephone station set, and then signal the tele- 
communication system to transfer the first tele- 
phone call to the covering telephone station set. 

25 One prior art system using this method of rerouting 
telephone calls is the SX 2000 telecommunication 
system manufactured -by Mitel Inc. In addition, this 
type of call rerouting is described in U.S. Patent 
5,036,535 for use in automatic call distribution 

30 (ACD) systems. This method of using H call trans- 
fer" to reroute the call does not forward the calling 
telephone number to the covering telephone station 
set and does not allow the call to be answered in 
an informative manner since the person using the 

35 covering telephone doesn't know who is calling. 

Whereas the two previously described methods 
of. rerouting telephone calls have provided this 
function for many years, these two methods suffer 
nevertheless from problems which become more 

40 severe as more modem telecommunication archi- 
tectures come into existence. The first method of 
rerouting calls suffers from the problem that the 
central processor must maintain extensive records 
with respect to all telephone station sets connected 

45 to the telecommunication switching system. In ad- 
dition to the maintenance of these records, the 
central processor has to be responsive to actu- 
ations of various buttons on each of the telephone 
* station sets to record the features invoked by those 

so buttons. This results in the telecommunication sys- 
tem having to maintain extensive records of what 
each button signifies on each individual telephone 
station set. This information has to be entered by 
the system administrator of the telecommunication 

55 switching system and is subject to error in addition 
to being a costly process to perform. The second 
method overcomes some of the problems of the 
first method but surfers from problems of its own. 
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© A telecommunication protocol message that al- 
lows redirection of a call received by a first tele- 
phone station set to a second telephone station set 
or other terminal equipment by the first telephone 
station set transmitting the redirect message to a 
telecommunication system connected to the first 
telephone station set. The redirect message includes 
the identification of the user of the first telephone 
station set as well as the telephone number of the 
second telephone station set or terminal equipment. 
The telecommunication switching system is respon- 
sive to the redirect message to reroute a call to the 
second telephone set. The redirect message allows 
the first station set to transmit only one message to 
the telecommunication switching system to accom- 
plish the functions of rerouting the call. In addition, 
the redirect message gives a BRI (basic rate inter- 
face) station set the capability of automatically for- 
warding certain types of calls. Since a call setup 
message includes the telephone number of the origi- 
nating station set, the BRI station set can be pro- 
grammed to transfer calls to different station sets 
based on the originating station number. In addition, 
with the proliferation of facsimile machines (often 
referred to as FAXs), there is a problem in coordinat- 



ing an individual's telephone number with the in- 
dividual's FAX number by a person wishing to send 
a FAX. Using the redirect message, the BRI station 
set can be programmed to examine the bearer capa- 
bility information encoded as an Information Ele- 
ment, IE, in the setup message to determine the 
type of call that is being set up. If a digital data call 
is being set up, the BRI station set then examines 
the higher layer capability IE in the setup message 
to determine whether or not it is a FAX message. If it 
is a FAX message, the BRI station set will automati- 
cally forward the call to the FAX designated by the 
user of the BRI station set. Further, the station set 
will display a message indicating that a FAX mes- 
sage had been forwarded. Using this technique it is 
only necessary to know a person's telephone num- 
ber in order to send a FAX to that person. 
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The main problem of the second method is the 
requirement of placing the first telephone call on 
hold and then performing a call transfer between 
the first and second calls. This places a load on the 
telecommunication switching system and is limited 
to the functions performed by the "call transfer" 
feature provided by the telecommunication switch- 
ing system. One such limitation imposed by the 
transfer feature is that the telephone number of 
covered telephone set is not communicated by the 
covering telephone station set. 

Summary of the Invention 



The foregoing problems - are solved, and a 
technical advance is achieved by an apparatus and 
a method in which a call received by a first tele- 
phone station set is rerouted to a second telephone 
station set or other terminal equipment by the first 
telephone station set transmitting a redirect mes- 
sage to a connected telecommunication system. 
The redirect message includes the identification of 
the user of the first telephone station set as well as 
the telephone number of the second telephone 
station set or terminal equipment. The telecom- 
munication switching system is responsive to the 
redirect message to reroute a- call to the second 
telephone set and provides the second telephone 
station set with the identification information of the 
first station set. Advantageously, the redirect mes- 
sage requires the first station set to transmit only 
one message to the telecommunication switching 
system to accomplish the functions of rerouting the 
call. 

In addition, the redirect message gives a BRI 
station set the capability of automatically forward- 
ing certain types of calls. Since the setup message 
includes the telephone number of the originating 
station set, the BRI station set can be programmed 
to transfer calls to different station sets based on 
the originating station number. In addition, with the 
proliferation of facsimile machines (often referred to 
as FAXs), there is a problem in coordinating an 
individual's telephone number with the individual's 
FAX number by a person wishing to send a FAX. 
Using the redirect message, the BRI station set can 
be programmed to examine the bearer capability 
information encoded as an Information Element, IE, 
in the setup message to determine the type of call 
that is being set up. If a digital data call is being 
set up, the BRI station set then examines the 
higher layer capability IE in the setup message to 
determine whether or not it is a FAX message. If it 
is a FAX message, the BRI station set will auto- 
matically forward the call to the FAX designated by 
the user of the BRI station set. Further, the station 
set will display a message indicating that a FAX 
message had been forwarded. Using this technique 



it is only necessary to know a person's telephone 
number in order to send a FAX to that person. The 
same type of operations can be performed by the 
BRI station set with respect to digital messages 
5 intended for a computer. These digital messages 
can he automatically transferred to the computer 
previously designated by the user of the BRI sta- 
tion set. 

Other and further aspects of the invention will 
70 become apparent during the course of the following 
description and by reference to the accompanying 
drawing. 

Brief Description of the Drawing 

75 

FIG. 1 illustrates, in block diagram form, a tele- 
communications switching system embodying 
the inventive concept; 

FIG. 2 illustrates the node hierarchy of the 
20 switching nodes of FIG. 1; 

FIG. 3 illustrates the dialing plan hierarchy of the 
switching nodes of FIG. 1; 

FIG. 4 illustrates a software architecture in ac- 
cordance with the invention; 

25 FIG. 5 illustrates, in block diagram form, the 

relationship between the software architecture 
and hardware elements illustrated in FIG. 1 ; 
FIGS. 6 and 7 illustrate routing tables utilized by 
the switching nodes; 

30 FIG. 8 illustrates, in block diagram form, the 
relationship between the software architecture 
and hardware elements for six switching nodes 
as illustrated in FIG. 1; 

FIGS. 9 through 12 illustrate routing tables uti- 
35 lized by the switching nodes of FIG. 1; 

FIG. 13 illustrates the physical layout of a node 

number of a switching node; 

FIG. 14 logically illustrates the signaling and 

transport paths that are set up within a switching 
40 node; 

FIG. 15 illustrates a software architecture for a 

link interface; 

FIGS. 16 through 19 illustrate, in greater detail, 
the software architecture for a link interface; 
45 FIGS. 20 and 21 illustrate, in greater detail, a 
software architecture for a network layer; 
FIG. 22 illustrates the logical structure of a call 
set up through the network, transport, and soft- 
ware layers; 

50 FIG. 23 illustrates, in flowchart form, the re- 
sponse of a transport layer to an indication from 
the network software layer; 

FIG. 24 illustrates, in flowchart form, the re- 
sponse of a transport layer to a request from a 
55 session software layer; 

FIG. 25 illustrates, in block diagram, form the 
response of a session software layer to an in- 
dication from a transport software layer; 
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FIG. 26 illustrates, in flowchart form, the re- 
sponse of a session software layer to a request 
from a presentation layer; 

FIG. 27 illustrates a front view of a remote 

switching module in a board carrier, 

FIG. 28 illustrates a rear view of a remote 

switching module in a board carrier; 

FIG. 29 illustrates, in block diagram form, a 

remote switching module; 

FIG. 30 illustrates, in block diagram form, a BRI 
station set; 

FIG. 31 illustrates a software architecture a BRI 
station set; and 

FIG. 32 illustrates, in flowchart form, operation 
performed by a terminal management applica- 
tion in response to a setup indication. 

Detailed Description 

FIG. 1 shows a telecommunications switching 
system having a plurality of switching nodes 101 
through 112 with a Network Management System 
(NMS) 115. Each of switching nodes 101 through 
112 provides communication for a plurality of tele- 
communications terminals such as BRI station sets 
120 through 130. The switching nodes of FIG 1 
function as an integrated system to provide tele- 
communication services. Switching nodes 106, 107, 
and 108 are interconnected to the other switching 
nodes via public network 114 and are providing 
telecommunication services to a group of people 
who are geographically remote from the people 
served by the other switching nodes. Each of the 
BRI station sets illustrated in FIG. 1 is capable of 
rerouting a call directed to each by utilizing the 
redirect message in accordance with the invention. 
For example, if. BRI station set 124 (connected to 
switching node 101) places a call to BRI station set 
120 (connected to switching node 102), BRI station 
set 120 can reroute this call to BRI station set 121 
(connected to switching node 105) by transmitting 
back a redirect message to switching node 102 in 
response to the initial message (setup message) 
received from switching node 102 specifying that 
the destination telephone number has been 
changed, including the telephone number of BRI 
station set 121, and the telephone number of BRI 
station set 120. Switching node 102 is responsive 
to the redirect message to examine internal routing 
tables and to direct the call from BRI station set 
124 to switching node 105. In addition, switching 
node 102 releases all call records and physical 
facilities associated with placing the call to BRI 
station set 120. Switching node 105 is responsive 
to the redirection of the call from switching node 
102 to interrogate internal routing tables and deter- 
mine that BRI station set 121 is interconnected to 
switching node 105 via BRI link 136. 



BRI station set 125 has been programmed to 
detect digital data calls and to transfer these digital 
data calls to FAX 146 or computer 149 using the 
redirect message. When BRI station set 125 re- 

5 ceives a setup message from switching node 104 it 
examines the bearer capability IE of the setup 
message to determine if this is a digital data call. If 
it is a digital data call, BRI station set 125 exam- 
ines the higher layer IE of the setup message to 

/o determine whether or not this is a FAX or digital 
data call intended for a computer. If it is a FAX, 
BRI station set 125 transmits back to switching 
node 104 a redirect message which specifies the 
telephone number of FAX 146. If it is a digital data 

75 call intended for a computer, BRI station set 125 
transmits a redirect message to switching node 104 
specifying the telephone number of computer 149. 
Switching node 104 is responsive to these redirect 
messages to transmit a setup message to the 

20 appropriate unit. Greater detail on the utilization of 
the redirect message by station sets and other 
communications terminals is given in the section 
entitled "Redirection of Calls by a Station Set". 

25 Background 

To understand how the redirect message is 
implemented, it is necessary to understand in 
greater detail the switching node hierarchy, dialing 

30 plan hierarchy, and the initialization of each individ- 
ual switching node. The following is an overview of 
the functions that are performed by each switching, 
node and NMS 115 during initialization and the 
adaptive learning of call routing. To reach the point 

35 where adaptive call routing is performed, each 
switching node as it becomes active must perform 
the following functions: (1) establish its own internal 
configuration, (2) identify and initialize interfaces, 
(3) establish its position in the switching node hier- 

40 archy, (4) obtain ownership for its portion of the 
dialing plan, and (5) learn how to route calls 
through the system. Each of these functions is 
described in general terms in the remainder of this 
section, and detailed descriptions are given in the 

45 following sections: the first function in "Internal 
Configuration Identification", the second function in 
"Initialization and Identification of Interfaces", the 
third function in "Node Hierarchy Identification", 
the fourth function in "Dialing Plan Initialization", 

so and the fifth function in "Call Routing". In addition, 
NMS 115 must establish a call to each switching 
node in order to distribute the dialing plan among 
the switching nodes and provide other manage- 
ment functions. The function performed by NMS 

55 115 is described in detail in the section entitled 
"System Network Management Initialization". 

To illustrate these functions, consider the ac- 
tions performed by switching node 102 in perform- 
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ing the first three functions. To accomplish the first 
function, switching node 102 establishes its own 
internal configuration with respect to the number of 
internal control processors (also referred to as an- 
gel processors), type of internal switching net- 
works, physical packaging (card carriers), and num- 
ber and type of link interfaces. After each of these 
entities becomes initialized and runs elementary 
diagnostic routines on itself, it signals the node 
processor (the main processor within a switching 
node, e.g., node processor 510 of FIG. 5) of its 
existence. 

To accomplish the second function (identify 
and initialize interfaces), each interface attempts 
independently to establish ISDN signaling across 
the link in switching node 102 attached to that 
interface. For example, the interface in switching 
node 102 attached to PRI link 150 attempts to 
establish the first two levels of ISDN protocol with 
the corresponding interface in switching node 101 
attached to PRI link 150. Interfaces in switching 
node 102 that are attached to PRI links 148, 150, 
and 160 and BRI link 135 also start initialization 
ISDN signaling on their respective links. In addition 
to the interfaces connected with the PRI links es- 
tablishing ISDN signaling, the interface connected 
to BRI link 135 within switching node 102 estab- 
lishes signaling with BRI station set 120. With re- 
spect to the BRI links, switching node 102 also 
performs a terminal endpoint identification (TEI) 
assignment procedure to identify station sets such 
as BRI station set 120. BRI station set 120 stores 
information defining its own identification number 
which in turn identifies its number within the dialing 
plan and its feature set. This information is commu- 
nicated to switching node 102 and used by switch- 
ing node 102 to make BRI station set 120 oper- 
ational. 

The third function (establish the position of a 
switching node in switching node hierarchy) is ac- 
complished by switching node 102 exchanging 
node numbers with switching node 101 after ISDN 
signaling has been established via PRI link 150. 
Each node number uniquely defines its switching 
node with respect to position in the switching node 
hierarchy. After the exchange of node numbers, 
switching node 102 immediately seeks to find the 
switching node which is next highest to it in the 
node hierarchy. In the present illustrative embodi- 
ment, FIG. 2 illustrates the switching node hierar- 
chy. In the system of FIG. 1, switching node 101 is 
the highest switching node in the node hierarchy. 
Switching nodes 102, 104, 105, 112, and 111 are 
directly subordinate to switching node 101. Switch- 
ing node 102 easily finds its switching node higher 
in the hierarchy since switching node 102 is di- 
rectly connected to switching node 101. 



Before the fourth function (obtain ownership for 
its portion of the dialing plan) can be accomplished 
by a switching node, NMS 115 must have distrib- 
uted to that initializing switching node and to 
5 switching nodes higher in the dialing plan hierarchy 
than the initializing switching node, information as- 
signing portions of the dialing plan that will belong 
to those switching nodes. However, NMS 115 does 
not give ownership of the numbers: For example, 

io as illustrated in FIG. 3, since switching node 102 is 
the highest node in dialing plan hierarchy, NMS 
115 only needs to distribute the plan to switching 
node 102. For switching node 111, the dialing plan 
portions have to be distributed to switching nodes 

75 102, 101 and 111 before switching node 111 can 
perform the fourth function. 

To perform the dial plan distribution, NMS 115 
must initialize the system management structure 
which comprises a switching network manager ap- 

20 plication in NMS 115 and system management 
applications in each of the switching nodes. The 
first step in the system network management initial- 
ization is for NMS 115 to place a call over PRI link 
148 to the system management application running 

25 in switching node 102. NMS 115 determined the 
existence of switching node 102 during the initial- 
ization of PRI link 148. (NMS 115 performs self 
initialization similar to a switching node with re- 
spect to interfaces.) NMS 115 utilizes the system 

30 management application of switching node 1.02 to 
extract information concerning what links are active 
on switching node 102 and to determine to which 
switching nodes these links are connected. Based 
on the node numbers received from switching node 

35 102, NMS 115 determines to which switching 
nodes it needs to establish contact. 
• In order to obtain information from switching 
node 101, NMS 115 places a call through switching 
node 102 to the system management application of 

40 switching node 101. (AH system management ap- 
plications have the same telephone number and 
are differentiated on the basis of the node number.) 
The system network manager, application running 
in NMS 115 uses this technique of calling through 

45 intermediate nodes to establish a session with the 
system management application in each of the 
switching nodes. 

In order to establish communications with 
switching nodes 106, 107, and 108, which are 

so interconnected with the remainder of the system by 
public network 114, the switching network manager 
application transmits information to switching node 
102 to cause that node to establish a flexible rate 
interface (FRI) link via PRI link 160, public network 

55 114, and PRI link 161 with switching node 106. 
Once the FRI link is established, the system net- 
work manager application can establish a session 
with each of system management applications in 
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switching nodes 106, 107, and 108. After establish- 
ment of the FRI link, switching node 106 can also 
establish its relationship in the node hierarchy to 
switching node 102. 

As soon as the switching management applica- 
tion running in NMS 115 has established a session 
with the system management application in switch- 
ing node 102 (in the present example), the dialing 
plan management application also running in NMS 
115 informs switching node 102 which portion of 
the dialing plan switching node 102 is to own. The 
dialing plan management application in NMS 115 
utilizes the routing information obtained b r y the 
switching network manager application in NMS 115 
during the process of initializing the system man- 
agement structure. Using this routing, the dialing 
plan management application establishes a session 
with the dialing plan application running in switch- 
ing node 102 by placing a call to the dialing plan 
application. 

As illustrated in FIG. 3, the dialing plan has a 
hierarchical structure in which certain switching 
nodes will own a larger portion of the numbers in 
the dialing plan than other switching nodes. The 
larger the portion of numbers owned by a switching 
node, the higher in dialing plan hierarchy that 
switching node is. A switching node owning a larg- 
er portion can also give other nodes groups of 
dialing plan numbers from that portion to own. The 
dialing plan is distributed in contiguous blocks of 
numbers to the switching nodes. In the present 
example, switching node 102 is the highest node in 
the dialing plan management hierarchy and is as- 
signed all of the numbers utilized by the system 
illustrated in FIG. 1. Switching node 101 is as- 
signed blocks of numbers defined by "1XXX" 
where the "X" denotes a don't care digit. However, 
switching nodes 105, 112, and 111 are also notified 
that they are to own three of the blocks, 10XX, 
11 XX, 12XX, respectively, that are presently owned 
by switching node 101. 

To accomplish the fourth function (obtain own- 
ership of a portion of the dialing plan), each switch- 
ing node upon being notified it should. own a cer- 
tain block of numbers finds its superior switching 
node in the dialing plan hierarchy by placing a call 
to its superior switching node and must ask per- 
mission from the superior switching node to own 
that block of numbers. For example, switching 
node 101 asks permission from switching node 102 
to own the 1 XXX block. Similarly, switching node 
105 requests permission from switching node 101 
to own the block that switching node 105 has been 
assigned. These requests are made by placing 
calls through the system to the dialing plan ap- 
plication of the higher switching node in the dialing 
plan hierarchy that controls the block being re- 
quested. For example, the dialing plan application 



of switching node 104 must place a call to switch- 
ing node 101 requesting a connection to the dialing 
plan application of. switching node 102 in order for 
switching node 104 to get permission to own its 

5 block of numbers. 

As a system is being brought up, the dialing 
plan may not be distributed to the higher nodes in 
the dialing plan hierarchy before nodes lower in the 
dialing plan hierarchy are requesting permission to 

ro own a particular block of numbers. When this oc- 
curs, the request is refused, and the requesting 
switching node tries at a later point in time. 

During the initialization of the network manage- 
ment hierarchy and the dialing plan hierarchy 

is which is part of the fourth function, the TEI assign- 
ment procedure of the second function has also 
■ been progressing with respect to the BRI station 
sets. This procedure is controlled by a terminal 
management application running* in each node. As 

20 part of the procedure, the terminal management 
application requests the service profile ID (SPID) 
information from a BRI station set. The SPID in- 
formation identifies, the terminal service profile 
(TSP) which defines the directory numbers plus 

25 features of the station set. The SPID information 
must be verified with the dialing plan application of 
the node with respect to assignment of the direc- 
tory number. In turn, the terminal management 
application must receive the service profile infor- 

30 mation from the system network management ap- 
plication in NMS 115. These procedures do not 
have to occur simultaneously. However, once the 
number has been verified with the dialing plan 
application, the switching node allows the station 

35 set to perform a specified restricted set of func- 
tions until the full set of functions can.be received 
from the system network management application. 
This feature allows the switching node to provide 
limited service until NMS 115 provides the direc- 

40 tory numbers and features. 

When the terminal management application re- 
quests from the local dialing plan application per- 
mission to use a particular number, that, dialing 
plan application may not own the number, but 

45 rather, the number is from a number block given to 
a dialing plan application on another node. For 
example, this situation occurs when a BRI station 
set connected to switching node 102 has a number 
defined in its TSP but switching node 102 doesn't 

so own the number block to which that number be- 
longs. Switching node 102 must request permis- 
sion from the other switching node owning the 
number to use but not own the number (referred to 
as hosting a number). Indeed, all numbers owned 

55 by a switching node may be hosted by other 
switching nodes. In order to host a number, the 
dialing plan application on. switching node 102 
must request permission from the dialing plan ap- 



6 



EP 0 550 179 A2 



12 



plication of the other switching node to host this 
number. The owning dialing plan application 
records the fact that it has allowed the dialing plan 
application of switching node 102 to host the num- 
ber and records the switching node on which that 
dialing plan application resides. To expand the 
hosting example, assume that BRI station set 120 
(connected to switching node 102) has a number in 
the "10XX" block which is owned by switching 
node 105. Switching node 102 has to obtain per- 
mission from switching node 105 to host this num- 
ber. The dialing plan application of switching node 
105 records the fact that switching node 102 is 
hosting that particular number. 

Until the service profile information can be re- 
ceived from the system network manager, each 
station set has only the features allowed by the 
restricted service profile. The restricted service 
profile gives the user of the station set basic func- 
tionality but this functionality is rather restrictive. 
The terminal management application within the 
node must request that the system management 
application in the node obtain the terminal service 
profile (TSP) from the system network manager 
application running in NMS 115. A session between 
the system network manager application and the 
system management application must have already 
had to have been set up by the fourth function. The 
obtaining of the TSP can take place at a much later 
point in time than the request to use a number 
since the station set has limited functionality al- 
ready. When the system network manager applica- 
tion receives the TSP request, it sends down a 
complete service profile record which designates 
what services this particular station set is to be 
allowed to use. 

To illustrate how the hosting and owning of 
numbers in the dialing plan functions consider the 
following example. In this example, BRI station set 
123 which is connected to switching node 111 is to 
use a number which is in the block of numbers 
owned by switching node 105. When the terminal 
management application in switching node 111 re- 
ceives the SPID from BRI station set 123, it re- 
quests permission from the dialing plan application 
executing in switching node 111 to use this num- 
ber. The dialing plan application determines that it 
does not own the requested number and transmits 
a request (by establishing a call) to the dialing plan 
application on whatever switching node owns the 
number. This switching node is found (if not al- 
ready known) by addressing the call to the number 
that switching node 111 wants to host and request- 
ing the dialing plan application for that number. 
The call is then routed by various switching nodes 
to switching node 105. Switching node 105 then 
delivers the call to the dialing plan application in 
switching node 105. 



The dialing plan application of switching node 
1 1 1 then transmits a request to the dialing plan 
application of switching node of 105 for permission 
to host the number. The dialing plan application of 

5 switching node 105 transmits permission to switch- 
ing node 111 for hosting the number, and switching 
node 105 marks in an internal table the fact that 
this number has been transferred to switching node 
111 for the purposes of being hosted. 

w To perform the fifth function (learn how to route 

calls through the system) in accordance with the 
invention, each individual switching node must ob- 
tain information on how to route calls through the 
remainder of the system after interfaces of the 

75 switching node have been established, the next 
highest switching node in the node hierarchy has 
been determined, the dialing plan has been distrib- 
uted to this particular switching node, and the TEI 
assignment procedure has been performed on the 

20 BRI station sets. Each switching node initially 
learns of how the switching nodes are intercon- 
nected by using information concerning the dialing 
plan hierarchy and the node hierarchy. In addition, 
when a call is placed to a destination switching 

25 node by an originating switching node, the destina- 
tion switching node includes, in the alerting mes- 
sage transmitted back to the originating switching 
node, the block of numbers owned by the_destina- 
tion switching node. 

30 The following examples illustrates how switch- 

ing nodes learn to route calls through the system. 
Consider the example where BRI station set 126 
which is connected to switching node 109 places a 
call to BRI station set 123 which is connected to 

35 switching node 111. The number (1201) of BRI 
station set 123 is both owned and hosted by 
switching node 111. After the number is dialed on 
BRI station set 126, switching node 109 examines 
this number to determine the switching node to 

40 which a setup message should be transported. 
Since node 109 has just come up, it only knows its 
own block of numbers (20XX) and the block of 
numbers (2XXX) for switching node 104. Hence, 
switching node 109 transmits a setup message to 

45 switching node 104 which is higher than itself in 
the dialing plan hierarchy. The routing to switching 
node 104 can be easily accomplished since switch- 
ing node 104 is directly connect to switching node 
109 and during the initialization of PRI link 158, 

so switching node 104 identified itself to switching 
node 109. Switching node 104 accepts the setup 
message from switching node 109, examines the 
message, and determines that it should route the 
call to switching node 102, since switching node 

55 102 owns (at least originally) all numbers in the 
dialing plan. This information was obtained during 
the dialing plan initialization. Switching node 104 
then establishes a path (by means of a call) 
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through itself and directs the call to switching node 
102 which is higher in the dialing plan hierarchy 
than switching node 104. To transfer the setup 
message to switching node 102, switching node 
104 first routes the call to switching node 101 
which is higher in the node hierarchy than switch- 
ing node 104 as illustrated in FIG. 2. Switching 
node 101 examines the number and determines 
that the message is destined for switching node 
102. Switching node 101 establishes a call through 
itself and then communicates the setup message to 
switching node 102. 

Switching node 102 determines from its inter- 
nal tables that the dialed number is a member of 
the blocks of numbers given to switching node 101 
as illustrated in FIG. 3. The call must be routed 
through switching node 101, but there is no need 
for the call to be routed from switching node 101 to 
switching node 102 and then back to switching 
node 101. To avoid this rerouting, switching node 
102 forms a redirect message and changes the 
destination node number to indicate switching node 
101 and sends the redirect message to switching 
node 101. In response to the redirect message, the 
latter switching node interrogates its internal tables 
using the dialed number, determines that the dialed 
number is a member of a block of numbers given 
to switching node 111, and transmits a setup mes- 
sage to switching node 111. Switching node 1 1 1 
determines that the dialed number is that of BRI 
station set 123 and commences to alert BRI station 
set 123 of the call. 

In addition, switching node 111 transmits an 
alerting message which contains the node number 
and the block of numbers owned by switching 
node 111. As the alerting message is transferred 
back through the previous path (via switching 
nodes 104 and 101) that was just described, each 
switching node inserts its own node number into 
the alerting message. When switching node 109 
receives the alerting message, it identifies the par- 
ticular block of numbers as belonging to switching 
node 111, stores the path defined by the node 
numbers, stores the block of numbers owned by 
switching node 111, and alerts BRI station set 126 
that BRI station set 123 is being alerted. 

The next time that BRI station set 126 places a 
call to BRI station set 123, node 109 examines its 
internal tables and determines that the dialed num- 
ber is to be routed to switching node 111. Con- 
sequently, switching node 109 transmits a setup 
message to switching node 104 designating (by 
including the node number of switching node 111) 
that the connection is to be made to switching 
node 111. Node 104 is responsive to the node 
number of node 1 1 1 in the setup message to use 
the node number for determining that it has a 
direct link to node 11 1 and to make that connection 



to node 111. 

Consider another example where a number 
dialed by BRI station set 126 is owned by node 
111 but the number is being hosted by node 112. 

5 During the TEI assignment procedure, switching 
node 112 requested permission to host the dialed 
number from switching node 111, switching node 
111 recorded the fact that switching node 112 is 
now hosting the number. In response to the dialing 

w of the dialed number, switching node 109 (to which 
BRI station set 126 is connected) examines this 
number and determines that the number is one 
which is part of a block owned by switching node 
111. This determination is based on information 

75 received from switching node 109 in the previous 
example. Switching node 109 then routes the setup 
message to switching node 111 via switching node 
104. Switching node 111 is responsive to the setup 
message to examine its own .internal table and 

20 determine that it has allowed switching node 112 to 
host the dialed number. Switching node 1 1 1 then 
passes the setup message to switching node 112 
which proceeds to alert the dialed station set, such 
as BRI station set 122, and to send an alerting 

25 message to node 109. 

After all of the nodes have been operational a 
short period of time, each node, within the system 
illustrated in FIG. 1 has developed information in its 
routing tables to enable it to route calls to the 

30 various BRI station sets connected to the system in 
accordance with the principles set forth by the 
previous examples. In addition, the switching nodes 
• are* capable of utilizing new paths through the sys- 
tem when a new PRI or BRI link becomes active. 

35 

Software Architecture 

FIG. 4 illustrates the software architecture of 
- the switching nodes of FIG. 1 . This architecture is- 

40 based on the conventional OSI model modified to 
implement the ISDN protocol. In accordance with 
the invention as described herein, certain further 
modifications have been made to the standard 
model in order to include ISDN capabilities. 

45 The principal function of physical layer 401 is 

to terminate physical links. Specifically, physical 
layer 401 is responsible for maintaining physical 
channels and for controlling physical subchannels 
thereon. Physical layer 401 comprises a software 

so portion and physical interfaces. Further, the soft- 
ware portion of physical layer 401 is responsible 
for the direct control of the physical interfaces to 
which physical links communicating PRI and BRI 
information terminate. Physical layer 401 presents 

55 to link layer 412 physical subchannels and physical 
channels as entities controllable by link layer 412. 

The primary function of link layer 412 is to 
assure that the information transmitted over a phys- 
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ical channel is recovered intact and in the correct 
order. This is accomplished using another layer of 
protocol which allows multiple communication 
paths — commonly referred to as logical links — to 
be established on a given physical channel or a 
physical subchannel communicating packetized 
data. These logical links are used to identify and 
process data being communicated between link 
layer 412 and physical layer 401. (An example of 
this type of protocol is the LAPD packet protocol 
used in ISDN Q.921. In the ISDN standard, link 
layer 412 terminates the LAPD protocol.) Link layer 
412 can support multiple protocols so that the 
upper layers are uneffected by the different pro- 
tocols being utilized. Further, link layer 412 allows 
higher software layers to control physical layer 401 
in an abstract manner. 

As seen in FIG. 4, link layer 412 is divided into 
link interface 402 and link management 403. The 
reason for this division is set forth herein below. It 
will be helpful at this point to discuss the commu- 
nication of- ISDN signals over a D channel to help 
readers, for example, who have only a rudimentary 
knowledge of the communication of ISDN signals 
over a D channel. At link layer 412, a plurality of 
logical links is established on a D channel. Only 
one of these logical links communicates ISDN con- 
trol signals, and this logical link is referred to 
herein as a logical D channel (LDC). The LDC is 
identified by a logical D channel number (LDCN). 

Link interface 402 does the majority of the 
functions performed by link layer 412, including the 
establishment of the logical links. Link management 

403 identifies the various link interfaces for higher 
software layers. Further, link management commu- 
nicates information between the logical links and 
higher software layers. 

Network layer 404 processes information com- 
municated on the LDCs, and thereby terminates 
the ISDN Q.931 protocol. Hence, this layer is re- 
sponsible for negotiating the utilization of system 
resources for the termination or origination of calls 
external to a switching node. The network layer 
controls the allocation of channels on an interface 
on which a call is being received or set up. For 
example, if switching node 101 receives a call from 
switching node 102 via PRI link 150, network layer 

404 of switching node 101 negotiates with its peer 
layer (the corresponding network layer 404 in 
switching node 102) in order to obtain allocation of 
a B channel in PRI link 150 -- a procedure later to 
be repeated if a second B channel is desired. This 
negotiation is carried out using standard ISDN 
Q.931 messages such as the call setup and con- 
nection messages via the LDC setup on the D 
channel of PRI link 150. Network layer 404 iden- 
tifies all B channels of given interface with the LDC 
for that interface. Network layer 404 is only con- 



cerned with the establishment of a call from one 
point to another point (e.g., switching node to 
switching node). The network layer is not con- 
cerned with how a call is routed internally to a 
5 particular switching node but rather transfers in- 
formation up to higher layers for the determination 
of how a call is routed in the switching node. 
However, the network layer does request that one 
application, referred to here and below as the con- 
w nection manager application, add or remove facili- 
ties on a physical interface to a switch connection 
within a switching node. 

Specifically, the network layer carries out call 
setup by first determining that the request for the 

15 establishment of a call is valid and that the re- 
sources between the two switching systems are 
available to handle this call. After this determina- 
tion, information concerning the call is transferred 
to higher software layers. The reverse is true when 

20 the network layer receives a request from the high- 
er software layers to establish a connection with 
another switching node. 

Network layer 404 receives information from 
another node concerning a call via a LDC. As 

25 information is received on the LDC, a call reference 
number is utilized to identify the call associated 
with this message. The call reference number is 
selected by the originating network layer during 
call setup in accordance with the ISDN standard. 

30 Details of this identification are given with respect 
to FIG. 14. 

Transport layer 405, is the key element that 
allows the routing of a call through a complex 
system having multiple nodes as illustrated in, FIG. 

35 1 . Its primary function is to manage the routing of 
calls externally, i.e., between switching nodes. 
Transport layer 405 views the system of FIG. 1 in 
terms of nodes and is concerned with routing calls 
from its own node to other nodes or endpoints. (As 

40 explained in the detailed discussion of session lay- 
er 406, that layer, not transport layer 405, interprets 
logical destination information, such as a telephone 
number, to determine the destination node of a call 
and to establish an intra-node path by using the 

45 connection manager application.) In an overall sys- 
tem comprising multiple switching nodes such as 
switching node 101, the various transport layers 
communicate with each other in order to establish 
a call through the various switching nodes. This 

so communication between transport layers is neces- 
sary because it may be necessary to route the call 
through intervening nodes to reach the destination 
node. The transport layers communicate among 
themselves utilizing signaling paths (LDCs) estab- 

55 lished between switching nodes. 

With respect to inter-node routing, transport 
layer 405 is the first layer that starts to take a 
global view of the overall system illustrated in FIG. 
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1. Transport layer 405 uses information provided 
by session layer 406 to select the inter-node path. 
The transport layer performs its task of routing 
between various nodes by the utilization of tables 
defining the available paths and the options on 5 
those paths. These tables do not define all paths 
but only those paths which the node has already 
used. 

Communication between transport layers is 
done by network layer 404 using established LDCs. w 
Transport layer 405 communicates information des- 
tined for its peers to network layer 404, and net- 
work layer 404 packages this information within the 
information elements, IEs, of standard ISDN Q.931 
messages. Network layer 404 uses the LDC that rs 
has been setup to a particular node to commu- 
nicate this information to its peer network layer. 
Similarly, when another network layer receives in- 
formation of this type, the other network layer un- 
packages information and then directs the informa- 20 
tion to the transport layer. 

The primary function of session layer 406 is to 
establish communication among endpoints with all 
endpoints considered to be applications including, 
for example, a BRI station set is considered an 25 
application. Significantly, these endpoints may be 
applications such as the application performing the 
calf processing features or the dialing plan applica- 
tion. In any event, connections between such end- 
points is considered a call. A session (call) is set 30 
up by session layer 406 any time two applications 
require communication with each other. As noted 
earlier, session layer 406 deals only in terms of 
switching nodes and applications on those switch- 
ing nodes and relies on transport layer 405 to 35 
establish paths to other switching nodes. Session 
layer 406 identifies the called application by an 
address which previously in the telecommunication 
art was thought of as only a telephone number but 
has a much broader concept in the Q.931 protocol. 40 
From this address, session layer 406 determines 
the destination switching node. Session layer 406 
sets up a call to the destination switching node by 
communicating with the session layer of the des- 
tination switching node. The communication with 45 
the other session layer is accomplished by having • 
the session layer request its transport layer to 
place a call to the other switching node so that a 
connection can be made for a particular address. 
The transport layer places the call relying on the so 
node number that was determined by the session 
layer. These requests are done using the network 
layer to generate standard ISDN Q.931 call setup 
messages. If the other switching node cannot inter- 
pret the address, the session layer of that switching 55 
node transmits information to its transport layer 
requesting that the call be dropped. If the session 
layer can interpret the address, it sends a message 



to its transport layer requesting that a call proceed- 
ing message be transmitted by its network layer 
back to the requesting switching node. 

Presentation layer 407 of FIG. 4. invokes a 
complex protocol in order to groom the information 
being communicated between applications so that 
the applications are totally divorced from the pro- 
tocol used to communicate the information. A pre- 
sentation level protocol allows an application to 
communicate with a peer application across a 
transport path. 

Finally, application layer 408 manages the re- 
sources needed by the applications running at soft- 
ware layer 409. When an application at software 
layer 409 is communicating with another peer ap- 
plication, the application is unaware of how many 
other applications exist or where these other ap- 
plications are located. It is the function of applica- 
tion layer 408 to determine and use such details, 
consequently allowing the applications to be written 
in a very abstract manner. At applications layer 
409, thus far five applications have been discussed: 
the system management, dialing plan, terminal 
management, connection manager, and call pro- 
cessing applications. 

Software Architecture Implementation - Over- 
view 



FIG. 5 illustrates in block diagram form the 
software architecture of FIG. 4 as implemented on 
switching nodes 101 and 102. Software layers 403 
through 409 are implemented on the main proces- 
sor of each switching node, such as node proces- 
sor 510 of switching node 101 and node processor 
501 of switching node 102. Specifically, the soft- 
ware layers down through the link management 
portion of the link layer are realized by software 
layers denoted 536 through 530 in node processor 
510 and software layers denoted 546 through 540 
in node processor 501 . 

The iink interface portion of the link layer is 
implemented by a number of separate software 
modules, each performing a link interface function. 
Each of these software modules is referred to as 
an "angel". These angels perform most of the 
functions of the link layer; and it is the task of the 
link management portion to simply provide a gate- 
way, or interface, from the various angels to the 
upper layers of the software structure. The link 
interface in node 101 is implemented by local 
angel 512 and remote angel 520. Local angel 512 
is a software module executed by node processor 
510. Remote angel 520 is a stand alone processor. 
The operation and purposes of remote angel 520 
are described in detail in our U.S. patent applica- 
tion, Serial No. 07/636,528, of B. M. Bales, et al. 
Case 5-1-2-1, filed December 31, 1990, entitled 
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"Transparent Remoting of Switch Network Control 
over a Standard Interface Link", having the same 
inventors and assignee as the present application. 
Correspondingly, the link interface in node 102 
comprises local angel 504. 

The physical layer is jointly implemented by 
hardware and software. Specifically, the hardware 
portion of the physical layer for switching node 101 
is implemented by interfaces 516 through 517 and 
interfaces 527 through 528. The software portion of 
the physical layer for interfaces 516 through 517 is 
performed by local angel 512 and for interfaces 
527 through 528 by remote angel 520. Interfaces 
516 through 517 and 527 through 528 are BRI 
and/or PRI interfaces of well-known types. Net- 
works 515 and 529 perform the required switching 
functions under control of local angel 512 and 
remote processor 520, respectively. At switching 
node 102, the hardware functionality of the physical 
layer is carried out by interfaces 506 through 509. 

A brief description is given of how a standard 
ISDN link is initialized with respect to the software 
layers. During the previous discussion of link inter- 
face layer 402 and physical layer 401 of FIG. 4, it 
was described how these two layers function to- 
gether to establish logical links on packetized ISDN 
D or B channels. Link management software layer 
403 identifies these logical links and communicates 
information to or from one of the logical links with 
any designated higher software layer. The destina- 
tion of the higher software layer occurs when the 
logical link is initialized. For example on a D chan- 
nel of a standard ISDN link, one specific logical link 
(referred to as a logical D channel, LDC) is always 
communicated to network software layer 404 in 
accordance with the ISDN specification. The LDC 
communicates all call control information for the B 
channels of the standard ISDN link and is an in- 
tegral part of the ISDN specification. 

Consider the initialization of a standard ISDN 
link. When a standard ISDN link becomes active, 
the physical layer identifies the physical interface 
number of that link to the link interface software 
layer. The link interface software layer uses the 
packet protocol on the D channel to identify what is 
on the other side of the interface by communicat- 
ing over a pre-specified logical link of the D chan- 
nel. The link interface software layer then informs 
the link management software layer that a new 
interface is active, that it has a certain number of B 
channels, and identifies to what the new interface is 
connected (if possible). The link management soft- 
ware layer informs the network software layer that 
a new interface is active and that it contains a 
certain number of B channels. 

In response, the network software layer records 
the new interface's existence and sets up tables to 
control the B channels. If call control signaling has 



not previously been established with the other side 
over a different interface, the network software lay- 
er assigns an LDC record to the interface and 
requests that the link management layer establish a 

5 signaling logical link with the other side. This re- 
quest is passed to the link interface layer which 
uses the LAP-D protocol to establish signaling. 
When the signaling logical link is established, the 
link interface layer notifies the link management 

w layer which notifies the network software layer that 
call signaling is active. Finally, the network software 
layer informs the transport software layer that a 
new LDC is active and to what system entity the 
new LDC is connected. 

75 After both sets of software layers (e.g. software 

layers 530 through 536 and software layers 540 
through 546) are initialized in this manner, calls 
may be established over the B channels associated 
with the LDC by the network software layers: Sig- 

20 naling information received or transmitted on the 
LDC is communicated between the network soft- 
ware layer and the link management software layer. 
In turn, the link management software layer com- 
municates this information with link interface soft-" 

25 ware layer for communication on the logical link of 
the D channel. For example, PRI links 150 and 148 
are established in this manner. 

Network Management Initialization 

30 

NMS 115 has a similar software structure as 
software layers 540 through 546; however, the ap- 
plications of NMS 115 are different than those in 
software layer 546. Once the LDC becomes active 

35 on PRI link 148, NMS 115 utilizes the system 
identification information received from switching 
node 102 to determine that NMS 115 is connected 
to switching node 102. Then, the system network 
manager application running in NMS 115 places a 

40 call to the system management application 548 
running at software layer 546 in node processor 
501. The call is directed to system management 
application 548 by utilizing the node number of 
switching node 102 and the specific telephone 

45 number which all system management applications 
share. Once the call is established between the 
system management application 548 and the sys- 
tem network manager application in NMS 115, the 
system network manager application requests that 

so the system management application 548 transfer to 
it from the management information base 563 in- 
formation relating to physical interfaces connected 
to switching node 102 (such as interface 506), 
switching nodes to which switching node 102 is 

55 connected (such as switching node 101) and the 
connected terminals (such as BRI station set 120). 
The system network manager application in NMS 
115 stores this information in the appropriate tables 
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and analyzes it to determine the switching nodes 
which are interconnected to switching node 102. 
The routing tables of switching node 102 are illus- 
trated in FIG. 6, which was populated during the 
initialization of switching node 102. 

As illustrated in FIG. 5, switching node 101 is 
interconnected to switching node 102 via PRI link 
150. NMS 115 places a call via switching node 102 
and PRI link 150 to system manager application 
538 in switching node 101. The signaling informa- 
tion required to establish such a call through 
switching node 102 is transmitted over the LDC 
established on the ID channel of PRI link 148. 
These signals are commonly called a setup mes- 
sage. The setup message is then processed by 
local angel 504, link management 540, and network 
layer 541 to present this setup message to trans- 
port layer 542. Transport software layer 542 ana- 
lyzes the node number utilizing routing table 602 
illustrated in FIG.. 6. Transport software layer 542 
determines that there exists an LDC to switching 
node 101 and requests that network software layer 
541 transmit the setup message to switching node 
101 . Network software layer 541 Jhen requests that 
link management software layer 540 transmit the 
setup message on the established LDC for switch- 
ing node 101. The message is then handled by the 
local angel 504 and transmitted to switching node 
101 via the LDC established on the D channel of 
PRI link 150. When the setup message arrives at 
transport software layer 532 after being processed 
by the lower software layers, software layer 532 
recognizes the node number as its own and utilizes 
the telephone number in the setup message to 
establish a session between system application 
538 and system network manager application in 
NMS 115. The session is established by transport 
software layer 532 requesting that a connection 
message be transmitted by network software layer 
531 back to the network software layer 541 of 
switching node 102. The session being established 
is a logical call and only requires that information 
be switched over LDCs. It is not necessary for the 
local angels to request that networks 508 and 515 
switch B channels. Once the session has been 
established between the system network manage- 
ment application of NMS 115 and system manage- 
ment application 538, the system network manager 
application requests that system management ap- 
plication 538 transfer to it from management in- 
formation base 561 similar information to that which 
was requested from system management applica- 
tion 548. The routing tables for switching node 101 
are illustrated in FIG. 6. The system network man- 
ager application in NMS 115 performs similar func- 
tions with respect to switching nodes 103 through 
112. 



Dialing Plan Initialization 

After the system network manager application 
has set up a session with each switching node, the 

5 dialing plan management application in NMS 115 
requests that a session be set up to the dialing 
plan application of that switching node. For exam- 
ple, the dialing plan management application re- 
quests that a session be set up to dialing plan 

w application 547 in switching node 102. When the 
session has been set up, the dialing plan manage- 
ment application gives to switching node 102 own- 
ership of all telephone numbers of the system 
illustrated in FIG 1. The dialing plan table for 

15 switching node 102 is illustrated as table 708 in 
FIG. 7 which also illustrates the changes in the 
routing tables of switching node 102. 

The numbers in the ownership column of ta- 
bles 708 and 711 of FIG. 7 have the following 

20 meaning: "1" means that a number block is owned 
by the node and received from the node listed in 
the node column, and "2" means that a number 
block has been given away to the node listed in the 
node column. A number block comprises a hun- 

25 dred numbers. The status column maintains the 
status of a permission request and whether a call 
still exists between two dialing plan applications. A 
"1 " means permission granted, a "2" means per- 
mission requested, and a "3" means that a call still 

30 . exists between the two dialing pan applications. 

Next, the dialing plan management application 
sets up a session to the dialing plan application 
537 of switching node 101 and informs dialing plan 
application 537 that it is to own numbers 1000 to 

35 1999 (IXXX block). No changes are made in the 
routing tables of switching node 101 until switching 
node 101 has received permission from switching 
node 102 to own this number block. In addition, the 
dialing plan management application informs dial- 

40 ing plan application 537 that the dialing plan ap-, 
plication 547 on switching node 102 is higher in 
dialing plan hierarchy than switching node 101. The 
dialing plan management application in NMS 115 
distributes the dialing plan to nodes 103 through 

45 112 by use of sessions in a similar manner. These 
sessions are set up by utilizing a setup message 
which is directed to the appropriate dialing plan 
application by use of the node number and a 
predefined telephone number which ws common for 

50 ail dialing plan applications. 

A dialing plan application (such as dialing plan 
application 537 of switching node 101) cannot ac- 
tually own a block of numbers until it has received 
permission to do so from the dialing plan applica- 

55 tion which owns the block. First, the two dialing 
plan applications must setup a session between 
themselves. For example, dialing plan application 
537 requests that transport software layer 532 set 
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up a call to dialing plan application 547. Transport 
software layer 532 accesses the node number 
(102) from the level 4 muting table for node 101 
illustrated in FIG. 6. The node number defines that 
link 150 is to be used for the call. This table is 
stored in management information base 561. 
Transport software layer 532 in conjunction with the 
lower software layers sets up a session with dialing 
plan application 547 in switching node 102. Once 
this call is set up, dialing plan application 537 
requests permission from dialing plan application 
547 to own the. blocks of numbers which were 
supplied to dialing plan application 537 by dialing 
plan management application in NMS 115. Refer- 
ring to FIG. 7, entry 704 of dialing plan table 71 1 
for switching node 101 initially has a "2" in the 
status column while dialing plan application 537 is 
requesting permission and then a "1" when per- 
mission is received from dialing plan application 
547 to own the "1XXX" block of numbers. Simi- 
larly, entry 705 in dialing plan table 708 is only 
present after dialing plan application 547 has given 
dialing plan application 537 permission to own the 
"1XXX" block of numbers. In addition, entry 702 of 
the level 5 muting table 706 of switching node 102 
illustrates the change made as a result of the 
actions of switching node 101. These changes in- 
dicate that switching node 101 now owns the 
"1XXX" blocks of numbers and that calls for num- 
bers within this block should be routed to switching 
node 101. Level 5 routing table 709 for switching 
node 101 has two entries made as a result of 
switching node 101 requesting permission to own 
the "1XXX" block of numbers. The dialing plan 
applications of switching nodes 103 through 112 
establish similar calls with the switching node 
which is higher in the hierarchy than they are and 
also obtain permission to own their destinated 
block of numbers. For similar operations, FIG. 9 
shows the results for the dialing plan tables and 
routing tables of switching nodes 101, 104, 109, 
and 111. 

Call Routing 

FIG. 8 illustrates from a software view point the 
software layers of switching nodes 101, 102, 104, 
109, 111, and 112. The switching nodes, as illus- 
trated in FIG. 8, are shown as' having the link 
management software layer, angels, networks, and 
interfaces combined into the unit called a periph- 
eral. For example, peripheral -840 of switching node 
102 includes local angel 504, network 508, inter- 
faces 506, 507, and 509 of FIG. 5. To understand 
how call routing is done in a first embodiment 
consider now in greater detail the example of rout- 
ing calls between BRI station set 126 connected to 
switching node 1.09 and BRI station set 123 con- 



nected to switching node 1 1 1 as illustrated in FIG. 
8. As signaling information defining the called tele- 
phone number (also referred to as the dialed num- 
ber) is received by switching node 109 from BRI 

5 station set 126 via the D channel of BRI link 140, 
that information is communicated to the call ap- 
plication 829. The dialed number is "1201". The 
call processing application 829 requests that ses- 
sion software layer 823 establish a call on the basis 

io of the dialed number. Session software layer ac- 
cesses level 5 routing table 916 of node 109 illus- 
trated in FIG. 9 and determines that it does not 
know how to route the call. (All tables are searched 
from top to bottom) As a default action, the session 

75 software layer decides to route the call to the 
switching node that has the dialing plan manager 
for the number "nearest" the dialed number, in this 
case, switching node 104. Session software layer 
823 then transmits down to transport software layer 

20 822 a request to route a setup message to switch- 
ing node 104. 

Transport software layer 822 .is responsive to 
this request to access level 4 routing table 917 
illustrated in FIG. 9 and to determine from entry 

25 904 that the LDC of PRI link 158 is to be used to 
access switching node 104. Transport software lay- 
er 822 then sends a request to network software 
layer 821 to transmit a setup message to switching 
node 104 with the dialed telephone number. Net- 

30 work software layer 821 in conjunction with periph- 
eral 820 transmits the setup message via PRI link 
158 to switching node 104. 

When the setup message is received by pe- 
ripheral 800, it is transferred to transport software 

35 layer 802 via network software layer 801. Transport 
software layer 802 recognizes the node number for 
switching node 104 and transfers the setup mes- 
sage to session software layer 803. Session soft- 
ware layer 803 accesses level 5 routing table 91 1 

40 of switching node 104 as illustrated in FIG. 9 to 
match the dialed number with one of the telephone, 
numbers entered in the table. The only telephone 
number that matches the dialed number is entry 
903 which identifies switching node 102. Session 

45 software layer 803 then requests that transport 
software layer 802 transmit the setup message to 
switching node 102 and include the telephone 
number. 

Transport software layer 802 accesses level 4 
so routing table 912 of switching node 104 to find a 
path to switching node 102. Transport software 
layer 802 matches at entry 908 of FIG. 9 and 
determines that the route to switching node 102 is 
via PRI link 155. The latter software layer then 
55 formulates a request to network software layer 801 
to transmit the setup message to switching node 
102 and includes the dialed number in this mes- 
sage. Network software layer 801 transmits the 

13 
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setup message via PRI link 155 to switching node 
101. 

When the setup message is received by trans- 
port layer 532 via peripheral 841 and network soft- 
ware layer 531, this transport layer accesses level 

4 routing table 914 for switching node 101 as 
illustrated in FIG. 9. The transport software layer 
finds a match for switching node 102 in entry 907. 
Based on this match, transport layer 532 makes a 
request to network software layer 531 to transmit 
the setup message to switching node 102 utilizing 
PRI link 150: Network software layer 531 is respon- 
sive to this message to transmit the setup message 
to switching node 102 via PRI link 150. 

When transport software layer 542 of switching 
node 102 receives the setup message, it examines 
the destination switching node number and deter- 
mines that it is its own. Transport software layer 
542 then communicates the setup message to ses- 
sion layer 543. Session layer 543 interrogates level 

5 routing table 706 for switching node 102 illus- 
trated in FIG. 7 and determines that the dialed 
number is part of a block of numbers designated 
entry 702 to which ownership had been given, 
switching node 1.01. As a result, session software 
layer 543 communicates to transport software layer 
542 a request to route the setup message to 
switching node 101. Transport software layer 542 is 
responsive to this request and the fact that the 
setup message was received from switching node 
101, to communicate a redirect message to net- 
work software layer 541 indicating that the destina- 
tion switching node had been changed to that 
switching node 101. The redirect message is sent 
back to switching node 101. 

When the redirect message is received by 
transport software layer 532 of switching node 101, 
this software layer communicates the redirection 
indication to session software layer 533. The latter 
software layer is responsive to the dialed number 
to access level 5 routing table 913 for switching . 
node 101 illustrated in FIG. 9. The dialed number 
(1201) matches entry 905 of FIG. 9. This entry 
designates that this number can be found on 
switching node 111. As a result, session software 
layer 533 transmits a request to transport layer 532 
to route the setup message to switching node 111. 
The latter" software layer is responsive to the re- 
quest to access level 4 routing tables 914 for 
switching node 111 as illustrated in FIG. 9 and to 
determine that switching node 1 1 1 can be reached 
via PRI link 153 as indicated by entry 906. Trans- 
port software layer 532 then communicates a re- 
quest to network software layer 531 to transmit the 
setup message to switching node 1 1 1 via PRI link 
1 53. Upon receiving the setup message via periph- 
eral 840, software layer 81 1 and transport software 
layer 812, session software layer 813 of switching 



node 1 1 1 determines that the dialed number re- 
ferences BRI station set 123. The latter software 
layer then transmit a request to the transport soft- 
ware layer 812 for the setup message to be com- 
5 municated to BRI station set 123. Upon receiving 
the setup request, BRI station set 123 responds 
with a alerting message. 

Before transmitting the alerting message back 
to switching node 101, transport software layer 812 

w accesses the ownership of number blocks owned 
by switching node 111 (number block 12XX) from 
management information base 818 and includes 
this information in the alerting message. The alert- 
ing message is transferred to switching node 101 

;5 and is routed to transport software layer 532. The 
latter software layer also inserts ownership informa- 
tion for blocks of numbers owned by switching 
node 101 before routing the alerting message to 
switching node 104. Transport software layer 802 is 

20 also responsive to the alerting message to insert * 
ownership information for blocks- of numbers owned 
by switching node 104. In addition, the transport 
software layer 802 stores the blocks of numbers 
owned by switching nodes .101 and 111 in its level 

25 5. routing table. Transport software layer 802 then 
transfers the alerting message to switching node 
109. Transport software layer 822 is responsive to 
the alerting message to route it to BRI station set 
126. In addition, transport software layer 822 stores 

30 the ownership information for blocks of numbers 
owned by switching node 104, 101, and 111. The 
result of the updating of the routing tables in this 
manner is illustrated in FIG: 10. 

To illustrate how the updated routing tables are 

35 utilized, consider that BRI station set 126 once 
again places a call to BRI station set 123. After the 
number has been dialed on BRI station set 126, 
this number is transferred to session software layer 
823 via call processing application 829. Session 

40 software layer 823 is responsive to the dialed num- 
ber to examine level 5 routing table 1007 for 
switching node 109 as illustrated in FIG. 10. A 
match is found for the dialed number in entry 1001 
which designates that the call should be routed to 

45 \ switching node 111, Session software layer 823 
then requests that transport software layer 822 
send a setup message to switching node 111. 

Transport software layer 822 is responsive to 
this request to examine level 4 routing table 1008 

50 for switching node 109 as illustrated in FIG. 10. A 
match is found for switching node 111 in entry 
1002. Entry 1002 indicates that the setup message 
is to be routed to switching node 111 via PRI link 
158. Transport software layer 822 requests that a 

55 setup message be sent to switching node 1 1 1 on 
link 158 including the dialed number, and this re- 
' quest is communicated to network software layer 
821. Network software layer 821 in conjunction with 
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peripheral 820 then transmits the setup message to 
switching node 104 via PRI link 158. 

When the setup message is received by trans- 
port software layer 802 of switching node 104, the 
latter software layer interrogates level 4 routing 
table 1006 for switching node 104 as illustrated in 
FIG. 10. Entry 1003 matches the destination 
switching node and indicates that the setup mes- 
sage is to be transmitted on PRI link 154. Trans- 
port software layer 802 requests that network soft- 
ware layer 801 transmit the setup message to 
switching node 111 via PRI link 154. Upon receiv- 
ing the setup message, switching node 111 trans- 
fers the setup message to BRI station set 123 and 
performs the previously described functions with 
respect to the alerting message which is received 
back from BRI station set 123. 

To further understand the routing of calls, con- 
sider the example where BRI station set 122 which 
is interconnected to switching node 112 via BRI 
link 137 requested during initialization to be given 
the number "1205". Since switching node 111 was 
given ownership of all "12XX" numbers, switching 
node 112 requested permission to host the number 
"1205". After giving permission to switching node 
112 to host that number, switching node 111 up- 
dated its dial plan and routing tables as illustrated 
in FIG. 11, and switching node 112 also updated its 
dialing plan and routing tables as illustrated in FIG. 
11. 

Referring back to FIG. 8, when BRI station set 
126 dials the number "1205", switching node 109 
in conjunction with switching node 104 routes a 
setup message designating switching node 1 1 1 to 
switching node .111 in the same manner as pre- 
viously described. When the setup message is 
received by switching node 111, transport software 
layer 812 communicates the message to session 
software layer 813. The latter software layer is 
responsive to the dialed number to access level 5 
routing table 1104 shown for switching node 111 in 
FIG. 11. Entry 1101 matches the dialed number, 
and session software layer 813 requests that the 
setup message be communicated to switching 
node 112. 

Transport software layer 812 is responsive to 
the request from layer 813 to interrogate level 4 
routing tables 1105 for switching node 111 and to 
determine that PRI link 166 is to be utilized for 
communicating the setup message. 

When the setup message is received by ses- 
sion software layer 833 of switching node 112, that 
software layer interrogates level 5 routing table 
1102 illustrated in FIG. 11, and determines that the 
BRI station set being dialed is attached to switch- 
ing node 112. Software layers 830 through 833 
then cooperate to transmit the setup message to 
BRI station set 122. The station set responds with 



an alerting message which is processed by the 
various software layers in switching nodes 112, 
111, 104, and 109 to update the routing tables in 
the manner previously described. The results of 

s this processing of the alerting message is illus- 
trated in the routing tables for switching node 104, 
109, and 111 as illustrated in FIG. 12. The routing 
tables of switching node 112 are identical to those 
shown in FIG. 11. 

io FIG. 12 illustrates how rapidly a switching node 

learns to route calls on the basis of the dialed 
telephone number and accumulates information for 
routing to specific switching nodes. The ability to 
learn new routes is important. A very good exam- 

75 . pie of this ability was switching node 104 taking 
advantage of the connection of PRI link 1 54 to 
switching node 1 1 1 rather than following the initial 
mute which was through switching node 101. If the 
capacity of PRI link 1 54 becomes totally utilized or 

20 this link becomes unoperational, then calls would 
once again be routed to switching node 111 from 
switching node 104 via switching node 101. If a 
new link is added to the system such as PRI link 
165 between switching nodes 102 and 105, the 

25 system quickly learns to utilize this newly added 
link. 

Consider now a second embodiment for doing 
call routing. Call routing in accordance with the first 
embodiment was described with respect to FIGS. 9 

30 through 12. In the first embodiment, each switching 
node receiving an alerting message inserted into 
that alerting message ownership information for 
blocks of numbers owned by the receiving switch- 
ing node and accessed from the alerting message 

35 ownership information for blocks of numbers owned 
by other switching nodes between the receiving 
switching node and the destination switching node 
in the call path. The first embodiment allows the 
level 5 routing tables to accumulate information 

40 regarding ownership of blocks of numbers at a very 
rapid rate. However, it greatly adds to the length of 
the alerting messages and to the time required to 
process each of these alerting messages. In the 
second embodiment, only the destination switching 

45 node inserts ownership information for the blocks 
of numbers owned by the destination switching 
node, and the intermediate switching nodes neither 
add nor extract ownership information as they pro- 
cess the alerting message back to the originating 

so switching node. The originating switching node 
does update its level 5 routing table with the own- 
ership information from the destination switching 
node. 

To understand how call routing is done in the 
55 second embodiment, consider the example of rout- 
ing calls for the first time between BRI station set 
126 connected to switching node 109 and BRI 
station set 123 connected to switching node 1 1 1 as 

15 
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illustrated in FIG. 8. The setup message is pro- 
cessed as was previously described for the first 
embodiment resulting in a call path between 
switching node 109 and switching node 111 being 
set up through switching nodes 104 and 101. When 
switching node 1 1 1 forms the alerting message, 
switching node 1 1 1 inserts into the alerting mes- 
sage its ownership information as illustrated in dial- 
ing plan table 918 of FIG. 9. The alerting message 
is then processed through switching nodes 101 and 
104 without these switching nodes performing any 
operations with .respect to ownership information. 
When the alerting message is received by switch- 
ing node 109, that switching node updates its level 
5 routing table. The result of this updating is illus- 
trated in level 5 routing table 1007 of FIG. 10 by 
entry 1001. The difference between the first em- 
bodiment and the second embodiment is that level 
5 routing table 1005 of node 104 as illustrated in 
FIG. 10 would have the first entry deleted so that it 
was equivalent to level 5 routing table 911 of FIG. 9 
for node 104. 

To illustrate how the updated routing table 
would be utilized in the second embodiment, con- 
sider that BRI station set 126 once again places a 
call to BRI station set 123. After the number has 
been dialed on BRI station set 126, this number is 
transferred to session software layer 823 via. call 
processing application 829. Session software layer 
823 is responsive to the dialed number to examine 
level 5 routing table 1007 for switching node 109 
as illustrated in FIG. 10. A match is found for the 
dialed number in entry 1001 which designates that 
the call should be routed to switching node 111. 
Session software layer 823 then requests that 
transport software layer 822 send a setup message 
to switching node 111. Transport software layer 
822 is responsive to this request to examine level 4 
routing table 1008 for switching node 109 as illus- 
trated in FIG. 10. A match is found for switching 
node .111 in entry 1002. Entry 1002 indicates that 
the setup message is to be routed switching node 
111 via PRI link 158. Transport software layer in 
conjunction with lower layers then transmits a 
setup message to switching node 104 via PRI link 
158. 

When the setup message is received by trans- 
port software layer 802 of switching node 104, the 
latter software layer interrogates level 4 routing 
table 1006 for switching node 104 as illustrated in 
FIG. 10. Entry 1003 matches the destination 
switching node number and indicates that the setup 
message is to be transmitted on PRI link 154. 
Transport software layer 802 requests that network 
software layer 804 transmit the setup message to 
switching node 111 via PRI link 154. Upon receiv- 
ing the setup message, switching node 1 1 1 trans- 
fers the setup message to BRI station set 123. This 



example illustrates that by utilizing the second em- 
bodiment for call routing that the switching nodes 
also perform adaptive call routing. 

In a third embodiment, a predefined number of 

s switching nodes along the path from the originating 
node insert and access ownership information from 
the alerting message. This enables switching nodes 
to learn very rapidly ownership information about 
switching nodes closely connected to themselves. 

w A fourth embodiment is where a predefined num- 
ber of switching nodes in the call path from the 
destination switching node insert and access own- 
ership information from the alerting message. The 
alerting message contains a sequential list of the 

75 switching nodes that make up the call path, and the 
third and fourth embodiments make use of this 
fact. In a fifth embodiment, a predefined number of 
switching nodes from the destination node and a 
predefined number of switching nodes from the 

20 originating node insert and access ownership in- 
formation from the alerting message. The fifth em- 
bodiment allows switching nodes to learn very rap- 
idly about the distribution of numbers local to 
themselves and at distant points but not about the 

25 distribution of numbers in intermediate switching 
nodes. 

Node Hierarchy Identification 

. 30 The node hierarchy is illustrated in FIG. 2, and 

the node numbers associated with each of. the 
switching nodes is illustrated in FIG. 13. As the 
system is being brought up, each switching node 
must establish its position in the switching node 

35 hierarchy. The node number as illustrated in FIG. 
13 consists of a network number which defines the 
network to which the switching node belongs and a 
node identification field which defines the switching 
node's hierarchical position within that network. The 

40 fields of the node number are separated by As 
previously described, when switching node 102 is 
initializing, it exchanges node numbers with switch- 
ing node 101. Upon receiving the node number for 
switching node 101 as illustrated in line 1301, 

45 switching node 102 can immediately determine that 
switching node 101 is its superior in the node 
hierarchy since the node identification field for 
switching node 102 as illustrated in line 1302 de- 
fers only by a zero in the most significant position. 

50 To consider an example where a node is not di- 
rectly connected to the switching node which is 
higher than itself in the node hierarchy, assume 
that in FIG. 1 that PRI link 151 is not present 
interconnecting switching nodes 105 and 101. As 

55 switching node 105 initializes, it is only intercon- 
nected to switching node 102 and 112. By exami- 
nation of the node identification fields illustrated in 
lines 1302, 1303, and 1304, switching node 105 
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can determine that switching nodes 102 and 112 
are at the same level in the node hierarchy as itself 
(as is illustrated in FIG. -2). However, switching 
node 105 through internal programming only needs 
to change the least significant field of the node 
identification area to a zero to obtain the switching 
node number of switching node 101. After deter- 
mining the switching node number of switching 
node 101, switching node 105 establishes a call to 
switching node 101 via either switching node 102 
or switching node 112 as illustrated in FIG. 1. In 
this manner, switching node 105 determines a path 
to the node which is higher in the node hierarchy 
than itself. Therefore, it can be seen from FIG. 13 
that the node number provides enough information 
for a switching node to determine the node number 
of the switching node higher in the node hierarchy 
than itself. Once a switching node has the node 
number of the node higher in the switching node 
than itsetf, it can establish the path to the higher 
hierarchical switching node by attempting to set up 
a call to that switching node. 

Initialization and Identification of Interfaces 

FIG. 14 logically illustrates the general relation- 
ships between data link connection identifiers 
(DLCI), service access point identifiers (SAPI), ter- 
minal end identifiers (TEI), system interface num- 
bers (sintf), switches angel interface numbers 
(aintf), logical D channel numbers (LDCN), call ref- 
erence numbers (CRN), and the various software 
layers. As illustrated in FIG. 14, each pair of link 
interface layers and physical layers is implemented 
on a different angels. Link interface layer 1425 and 
physical layer 1426 are implemented by local an- 
gel 512, and link interface layer 1427 and physical 
layer 1428 are implemented by remote angel 520. 
Node processor 510 implements link management 
530, network 531, and higher layers. Sintf, switch 
and aintf numbers correlate to physical interfaces. 
The sintf numbers are utilized by network software 
layer 531 and higher software layers to identify 
physical interfaces. Network layer 531 views the 
physical interfaces as being identified by sintf 1 
1401 through sintf4 1404. Link management 530 
makes a conversion between the sintf numbers and 
the switch and aintf numbers which together repre- 
sent the physical interface. For example, link man- 
agement 530 converts sintf 1 1401 to local angel 
512 and aintf 1 1411. Link interface layer 1425 
utilizes aintf 1 1411 to identify physical interface 
516. There is a one for one correspondence be- 
tween sintf 1 1401 through sintf6 1404 and aintf 1 
141 1 through aintf2 1414. 

The sintf and aintf numbers identify specific 
interfaces, and each interface has a number of 
channels. For example, PRI link 150 has 24 chan- 



nels, and BRI interface 517 has three channels. 
Network layer 531 identifies the channels asso- 
ciated with a particular sintf by using the actual 
physical channel numbers, and similarly, link inter- 

5 face layer 1425 utilizes the physical channel num- 
bers in association with an aintf number. This is 
possible because the specifications of the ISDN 
standard designate that physical' channel 24 is 
used to perform signaling. Network layer 531 and 

w higher layers utilize sintf numbers in order to con- 
trol the link interface layers and physical layers to 
interconnect physical channels and to create spe- 
cific protocols on these channels. The manner in 
which B channels are interconnected through phys- 

75 ical networks such as network 515 is not illustrated 
in FIG. 14 except in a logical manner, e.g. path 
1407. 

Further, FIG. 14 logically illustrates the utiliza- 
tion of the various channels and the points at which 

20 these channels are terminated and at which in- 
formation is utilized. B channel 1432 of interface 
516 is interconnected to B channel 1433 of inter- 
face 517 by path 1407. Path 1407 is made through 
network 515 which is not shown in FIG. 14 but is 

25 shown in FIG. 5. It would be obvious to one skilled 
in the art that similar paths could be made between 
B channels in interface 516 and 517. The circuit 
switching of B channels is performed at the phys- 
ical layer; whereas, packet switching or frame re- 

30 laying is performed at the link interface layer. 

The manner in which a LDC is set up is de- 
scribed in greater detail with respect to FIG. 15 and 
is not repeated at this point. However, FIG. 14 
illustrates the manner in which D channel 1430 is 

35 subdivided so as to provide the necessary flow of 
information to implement a LDC. At physical layer 
1426, all channels are treated alike. First, link inter- 
face layer 1425 under control of higher layers 
establishes a LAPD packet protocol on D channel 

40 1430 which is channel 24 of PRI link 150. The 
LAPD packet protocol creates a plurality of logical 
links 1417 each of which is identified by a DLCI 
number such as DLCI 1428. A DLCI number is 
based on the TEI and SAPI numbers with each pair 

4S of TEI and SAPI numbers designating one DLCI or 
logical link. The protocol allows for a 128 TEI 
numbers and 63 SAP numbers. D channel 1434 is 
subdivided in the same manner as D channel 1430. 
In accordance with the ISDN specification, a 

so physical link can be considered either as point-to- 
point or point-to-multi-point. By convention, a PRI 
link may only be point-to-point resulting in only one 
TEI number being allowed on the D channel of a 
PRI link. Further by convention, that TEI number is 

55 equal to 0. A BRI link may be point-to-point or 
point-to-multi-point resulting in a D channel of BRI 
potentially having more than one TEI number. In 
accordance with the ISDN specification, four of the 

17 
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SAPI numbers of a D channel are predefined as 0 
for call control, 16 for implementing a X.25 pro- 
tocol, 1 for a packet mode connection, and 63 for 
peer to peer communication between link manage- 
ment layers. In FIG. 14, SAP 1408 has the value of 
63 and is used by link management 530 for com- 
munication with its peer in the present example on 
switching node 102. SAP 1409 has a value of 0 
and is used to implement LDCN 1419. In the 
present example, the SAPs having values of 16 
and 17 are not implemented. The remainder of the 
60 SAP values may be utilized to establish packet 
connections for the communication of data for soft- 
ware layers above network software layer 531 - 
SAPs 1442 and 1443 correspond to SAPs 1408 
and 1409 in function. 

AM signaling is controlled via LDCN 1419 for 
interface 516. Upon receiving a SAPI of 0 which is 
SAP 1409, link management 530 directs this to 
network software layer 531. In accordance with the 
ISDN specification, call reference numbers are in- 
cluded in the Q.931 protocol and are received via 
LDCN 1419. These call references numbers are 
utilized to identify call records such as call record 
1421 or 1423. For example, CRN 1420 and 1422 
identify call record 1421 and 1423, respectfully. 
There is one call record for each channel or chan- 
nel that is engaged in a circuit switched or pac- 
ketized call on a physical interface. A call record is 
established for setup message when that message . 
is first received. Link management 530 utilizes 
sintfl 1401 to associate LDCN. 1419 with, call 
records 1421 and 1423. At network software layer 
531 , CRN numbers are only unique with respect to 
an individual LDCN. CRN 1445 and call record 
1444 are similarly associated with LDCN 1441. 

FIG. 15 illustrates the messages that are ex- 
changed in bringing up an interface on switching 
node 101 of FIG. 5. A physical interface, firmware 
1510, which includes link interface layer 1512 and 
physical layer 1513, is physically being implement- 
ed on either local angel 512 or remote angel pro- 
cessor 520. First, consider FIG. 15 from the point 
of view of physical interface 516 of FIG. 5 which is 
being bought up. Initially as an interface is plugged 
in (path 1518), physical layer transmits the 

mph_info ind 1500 primitive which is directed to 

L2 MGMT ENTITY 1607 (a level 2 management 

entity which is described in detail with respect to 
FIG. 16). Note, the service access point (SAP) 
number is a 63 for a MDL primitive and a zero for a 
DL primitive. Primitive 1500 also includes the aintf 
which the angel selects. The aintf is the reference 
used by 

L2 MGMT ENTITY 1607 to refer to that inter- 
face. Primitive 1500 also defines the type of inter- 
face, such as a PRI, BRI or FRI link, that has been 
brought up. Note, that the mnemonics indicate 



where the message is from and where it is going. 
MPH means that the message is between the 
physical layer and the level 2 management entity, 
MDL indicates that message is between the level 2 

5 management entity and the LAPD portion of link 
interface layer 1512, and DL indicates that mes- 
sage is between level 5 and the LAPD portion of 
link interface layer 1512. 

When physical layer 1513 detects framing 

10 (path 1519) on the interface, physical layer 1513 
communicates this fact to entity 1607 by the trans- 
mission of MPH ACTIVATE IND 1501 primitive. 

To completely respond to primitive 1501, entity 
1607 needs to establish with the other interface the 

75 terminal endpoint identifier (TEI). The TEI is deter- 
mined through negotiations with the other interface. 
To accomplish this negotiation, entity 1607 com- 
municates with its peer level 2 management that is 
controlling the other interface. For example, as- 

20 sume that the indication . on path 1519 resulted 
from a BRI interface becoming active by a tele- 
phone being plugged into the BRI interface. Most 
. BRI telephones are programmed to negotiate .the 
TEI specified by the ISDN standard in response to 

25 Q.921 messages received via the BRI interface. If 
the active interface is not a BRI interface which 
supports the automatic TEI procedures, primitives 
1502 and 1503 are not exchanged. Entity, 1607 
starts, the TEI negotiation by sending the 

30 MDL_UDATA REQ 1502 primitive that contains a 

TEI selected by entity 1607 to layer 1512. In re- 
sponse, layer 1512 transmits Ul 1520 (unumbered 
frame). The peer entity responds to Ul 1520 via its 
interface with Ul 1521 that contains an indication of 

35 the peer entity's agreement with TEI selected by 
entity 1607. In response to Ul 1521, link interface 
layer 1512 inserts the indication into 

MDL__UDATA IND 1503 primitive. The CCITT 

ISDN specification allows for other commands at 

40 this point that allow for further negotiation of the 
JEV if entity 1607 selected a TEI that was already 
being used by the telephone. 

Entity 1607 responds to primitive 1503 by 
transmitting MDL_ASSIGN REQ 1514 primitive 

45 to link interface layer 1512. This primitive contains 
information requesting that link interface layer 1512 
make an allowance for every possible SAPI iden- 
tifier that can be associated with the. negotiated 
TEL As explained with respect to FIG. 14, the SAPI 

so defines how a logical link is being used; whereas, 
the TEI simply identifies a terminal on the other 
side. The request for link interface layer 1512 to 
make allowance for SAPI identifiers makes provi- 
sion for entity 1607 to establish these SAPI identifi- 

55 ers at a later point. 

Now, entity 1607 transmits a 
MDL UDATA REQ 1504 primitive whose infor- 
mation contains the address of a specific TEI and 
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the node number of node 101. Primitive 1504 is 
converted by layer 1512 to Ul 1522. The reason for 
sending the node number using primitive 1504 is to 
determine whether the other peer entity is a switch- 
ing node such as switching node 102. The other 
entity may also be a public network or a BRI 
telephone. In response to Ul 1522, if the other 
entity is a node, it responds with its node number 
by the transmission of Ul 1523 whose information 
includes the other entity's node number. Layer 
1512 responds to Ul 1523 by transmitting 
M D L U DATA I N D 1505 primitive. If the other en- 
tity is not a node, it fails to recognize Ul 1522 and 
does not respond, resulting in a time out. In re- 
sponse to the time out, entity 1607 via path 1509 
communicates LINK AVAIL 1511 primitive to en- 
tity 2001 which is described in greater detail with 
respect to FIG. 20. At this point, entity 1607 has 
accomplished the following functions: framing has 
been established, the TEI has been identified, link 
interface 1512 has been advised to prepare for the 
establishment of different services via SAP! identifi- 
ers such as signaling, an attempt has been made 
to exchange node numbers, and the determination 
has been made that the interface is now ready to 
be used by higher layers. Entity 1607 now advises 

entity 2001 via the LINK AVAIL 1511 primitive that 

the interface is now ready for use and whether or 
not the interface is a switching node. 

Entity 2001 has to determine whether to estab- 
lish a signaling link with the other entity. If entity 
2001 already has a signaling link to the other peer 
entity in another switching node, entity 2001 does 
not proceed with primitives 1506 and 1507. Entity 
2001 has a signaling link with the other entity if the 
switching node of the other peer entity has an 
established interface with switching node 101. If 
entity 2001 heeds to establish signaling, entity 

2001 transmits a DL ESTABLISH REQUEST 

1506 primitive which contains information request- 
ing that a signaling link (LDC) be established to the 
other entity. Layer 1512 converts primitive 1506 to 
SABME 1524. If the other entity agrees, it transmits 

UA 1525 back which layer 1512 converts to DL 

ESTABLISH CON 1507 primitive. After receipt of 

primitive 1507, entity 2001 transmits a 

LDCN AVAIL message to transport software layer 

532 advising the transport software layer that a new 
LDC has become available. In addition, the 
LDCN AVAIL message also informs transport soft- 
ware layer 532 whether the LDC is communicating, 
with another switching node, central office, long 
distance network, a telephone, or an unidentified 
entity. 

In forming the DL ESTABLISH REQUEST 

1506, entity 2001 uses the node number received 

in LINK AVAIL 1511 primitive to determine the 

position of the new node within the node hierarchy. 



As previously mentioned, each node has a unique 
node number, and the number itself determines the 
position within the node hierarchy. In addition, this 
information is utilized to decide which entity is 

5 going to be the user or the network on a PRI 
interface. If this relationship is not correct on a PRI 
link, the link will not become operational. Before 

the transmission of DL ESTABLISH REQUEST 

1506, the signaling link has not yet been estab- 

w lished so that the determination of user and net- 
work has not been made. Primitives 1501 through 
1505 occur before any LAPD link is established. 
For this reason, all the frame commands are un- 
numbered. This frees the entities from having to 

75 determine the network and the user destinations. 
Before the transmission of primitive 1506, entity 
2001 compares the node numbers and from this 
comparison determines which of the entities will be 
defined the user or the network. For other entities 

20 such as the public network, this destination is 
specified. If the other entity is unknown with re- 
spect to. being a network or a user, entity 2001 
initially tries to come up as a user when transmit- 
ting out primitive 1506. If this fails, entity 2001 

25 determines this after a timeout period is exceeded. 
If a timeout occurred, entity 2001 then transmits 
out a second primitive 1506 designating itself as 
the network. 

Link management 530 is shown in greater de- 

30 tail in FIG. 16. Link management 530 consists of 
blocks 1601, 1606, and 1607 and queues 1602 
through 1605. Using queues 1602 through 1605, 
L2 IO 1601 communicates data with link inter- 
faces such as link interface 402 of FIG. 4 in local 

35 angel 512. L2_PRIM_HANDLER 1606 is con- 
cerned with receiving and placing information into 
queues 1602 through 1604 from network software 
layer 531. Block 1606 also makes the determina- 
tion of whether information should be transferred to 

40 network software layer 531 or to 

L2 MGMT ENTITY 1607. In addition, block 1606 

performs the mapping between the sintf number 
and the switch and aintf number. 
L2 MGMT ENTITY 1607 is concerned with per- 

45 forming the functions of layer management 210 at 
the link management level. 

L2 IO 1601 is illustrated in greater detail in 

FIG. 17. Que uplink 1701 transfers information 

received either from the VIM application or remote 

so angel handler application or local angel 512 into 
12_13q 1605. 

The remote angel handles the L2-L3 function, 
the communication handler function, and the layer 
management which are running in the remote an- 

55 gel. Greater detail on the operation of the remote 
angel is given in the previously referenced copen- 
ding application. Information flows directly from 
queues 1602 through 1604 to either the applica- 

19 
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tions or the local angel. The queues are initialized 

by i queues 1702 under control of the system 

task dispenser. Blocks 1701 and 1702 are subrou- 
tines which are called by the appropriate entities. 

L2 prim handler 1606 is illustrated in greater 

detail in FIG. 18. With respect to data received 
from the different angels, block 1606 determines 
whether this information should be transferred to 
network software layer 531 or 
L2 MGMT ENTITY 1607. This function is per- 
formed by from 12 1804 which reads the primi- 
tives contained in queue 1605. Note that block 
1804 is periodically invoked by the system task 
dispenser to remove primitives from queue 1605 
(this is indicated by oval 1806). Block 1804 makes 
the decision of where to transfer the primitives 
stored in queue 1605 by examining these primi- 
tives. If the primitive starts with a DL mnemonic, 
the primitive is to be transferred to network soft- 
ware layer 531; if the primitive starts with a mne- 
monic of MDL or MPH, the primitive is to be 
transferred to L2_MGMT — ENTITY 1607. The 
primitives transferred to or from 

L2 MGMT ENTITY 1607 are in three general 

classes. The first of these classes is information 
concerning the physical status of links in switching 
node 101. The second class is signaling being 
received from another link management layer in 
another node. An example of the second class is 
the signaling that occurs between switching node 
102 and switching node 101 as described with 
respect to FIG. 15. With respect to second class, 
the overall function provided by 

L2 MGMT ENTITY 1607 is to negotiate with its 

corresponding peer to establish node numbers and 
to bring up an interface! The third class is the 
control of the interfaces within switching node 101. 

Returning to FIG. 18, if from_12 1804 deter^ 
mines that the primitive is not to be transferred to 
block 1607 of FIG. 18, block 1804 maps the switch 
and aintf numbers to the sintf number by invoking 

map to sintf 1803. After obtaining the sintf, 

from 12 1804 transfers the primitive to the net- 
work software layer 531 . Messages coming from 
network software layer 531 are first processed by 

downlink 1802 which invokes map to aintf 1805. 

The latter subroutine converts the sintf number to 
the switch and the aintf numbers. Once the switch 
and aintf numbers have been obtained, downlink 

1802 invokes que dlink 1801. Also, downlink 1802 

converts the message protocol received from net- 
work software layer 531 into an intra-link level 
protocol resulting in the primitive being transferred 
to subroutine 1801 which then places the primitive 
in queues 1602, 1603, or 1602 based on the switch 
number. 

Now consider information which is being re- 
ceived by que dlink 1801 from 



L2 MGMT ENTITY 1607 as illustrated in FIG. 18. 

In explanation of the type of information that is 
being transferred from block 1607 to subroutine 
1801, reference is now made to FIG. 19. During 

5 initialization of an interface, block 1901 activates 
certain subroutines in block 1902. Once activated, 
these subroutines activate other subroutines in 
block 1904. The subroutines in block 1904 transmit 
messages to the physical or virtual interface being 

10 initialized. Examples of subroutines in block 1902 
activated by messages from an interface to trans- 
mit messages back to the link interface via block 
1904 is given with respect to FIG. 15. For example, 
when node numbers are to be exchanged, subrou- 

75 tine MDL UDATA IND of block 1902 is activated 

which in turn activates subroutine 
MDL UDATA REQUEST of block 1904. In addi- 
tion, the subroutines of block 1902 utilize the sub- 
routines of block 1903 to find sintf and intfrec 

20 numbers. L2_MGMT_ ENTITY 1607 assigns the 
sintf numbers when a new interface ts established 
and allocates memory for the interface within a 
management information base such as manage- 
ment information base 561. In addition, entity 1607 

25 frees sintf numbers when an interface is discontin- 
ued. The functions of entity 1607 are performed in 
conjunction by subroutines in blocks 1902 and 
1903 of FIG. 19. Block 1906 is utilized by the 
system task dispenser to initialize the intfrec and 

30 sintf numbers. In addition, some of the subroutines 
in block 1902 can transmit information up to the 

management entity (L3 MGMT ENTITY 2001 

shown in FIG. 20) 

FIG. 20 illustrates a detailed block diagram of 

35 network software layer 204. There are two paths 
flowing between software layers. One is a signaling 
path which is designated as paths 1610 and 1611, 
and the other one is a management information 
path which allows management entities to commu- 

40 nicate and is designated as paths 1612 and 2012. 
An* example of management information stored in a 
management information base such as manage- 
ment information base 561 is the sintf number 
which is inserted by entity 1607, but the sintf is 

45 also used by different management entities in high- 
er layers. Another example is the framing indication 
for an interface which is placed in the management 
information base by entity 1607. The management 
entity of the transport software layer utilizes this 

so framing indication to determine whether or not it 
has a transport connection to a particular node. 

In FIG. 20, L3_PROCESSING 2002 is respon- 
sible for communicating signaling information to 
and from link management 530. 

55 L3 MGMT ENTITY 2001 is responsible for es- 
tablishing and removing signaling paths which are 
used for connections. For example, block 2001 
initially transmits the setup message to initiate the 
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setting up of a call. This message is transferred 
down to link management 530 for transmission. 
Q.931 block 2003 is responsible for all protocol 

handling. INTF MANAGER 2004 is responsible for 

interfacing with transport software layer 532. 

L3_PROCESSING 2002 is illustrated in great- 
er detail in FIG. 21. As information is received from 
link management 530, l23work 2101 decides 
whether the messages should be transferred to 

L3 MGNT ENTITY 2001 or to subroutines 2103 

through 2105. Subroutine 2103 processes primi- 
tives from the link layer which are not recognizable 
and simply records the fact that such a message 
has been received. Block 2104 can be used to 

receive the DL UDATA IND primitive. 

L3 dl data ind 2105 handles actual signaling 

messages when called from 123work '2101. Sub- 
routine 2105 handles the Q.931 messages and 

transfers these to msg preproc 2107. Subroutine 

2107 does some of the initial Q.931 verification of 
the message. These functions include assuring that 
the protocol discriminator specifies one of the 
Q.931 protocols, checking the call reference value, 
and checking the message type to assure that it is 
a valid message type. The call' reference value is 
checked for being a valid value and whether it 
refers to currently active call or a new call for 
which resources are available within switching node 
101 to handle. 

Msg_preproc 2107 either transfers the mes- 
sage to Q.931 block 2003 or to one of the state 

machines, GST A STM 2006 or L3STA STM 

2005 of FIG. 20. If the message is a global mes- 
sage, it is passed to state machine GSTA STM 

2006. (A global message is one that effects every 
call on an entire interface, such as a reset on a PRI 
link.) State machines 2005 and 2006 take care of 
particular types of messages and utilize block 2003 
to process these messages. If the call reference 
value indicates a regular message, state machine 
2005 is called. If the call reference value is null, 
then block 2002 passes this message directly to 
block 2003, since no state processing is required. 
In addition, if block 2107 of FIG. 21 determines that 
it has received an incorrect message, it transfers a 
message up to block 2003 of FIG. 20 requesting 
the transmission of a Q.931 message back to the 
other side informing the other side that an invalid 
message was received. (An example of an invalid 
message is an invalid protocol discriminator.) When 

msg preproc 2107 is processing the message 

from link management, it utilizes find Idcn 2106 to 

determine the translation between the sintf number 
and the LDCN. The LDCN is used to identify mes- 
sages to the entities above l_3_PROCESSING 
2002. During the establishment of signaling by 

L3 MGMT ENTITY 2001, block 2001 defines the 

correspondence between the LDCN and sintf num- 



ber. The output of Q.931 block 2003 flows directly 
through block 2002 since block 2003 has formatted 
the message for link management 203. However, 
messages from L3 MGMT ENTITY 2001 must 

5 first be formatted by subroutine send 12 2102 

before being transferred to link management 203. 

Note, when L3 MGMT ENTITY 2001 selects the 

LDC, block 2001 reports this number up to the 
management entity at the transport level via path 

w 2012 of FIG. 12. 

Consider elements 2003 through 2008 of FIG. 

20. GSTA STM 2006, L3STA_STM 2005, and 

14STA_STM 2007 represent information being 
placed into state queues for execution by the sys- 

;s tern task dispenser. For example, when 
L3_PROCESSING 2002 receives a global call ref- 
erence value, it places information into the queue 

for GSTA STM 2006 which results in the system 

task dispenser initializing the global state machine 

20 resulting in a call to block 2003. Task 2005 handles 
messages which have a specific call reference 
value and initiates, under control of the system task 
dispenser, the appropriate routines within block 
2003. 

'25 Block 2003 is responsible for performing all of 

the Q.931 protocol handling. The functions per- 
formed by block 2003 in processing the Q.931 
protocol are clearly defined in the CCITT Blue 
Book specifications. Ovals 2005 and 2006 repre- 

30 sent the execution of a task by the system task 
dispenser. These tasks handle particular types of 
call reference values and perform their work by 
calling specific parts of block 2003; whereas the 
tasks represented by ovals 2005 and 2006 are not 

35 directly specified by the ISDN specifications their 
functions are. The purpose of showing a task being 
initiated out of the ovals is to indicate that the 
system task dispenser controls the initialization of 
these tasks. For example, oval 2008 represents the 

40 request that block 2004 be executed when informa- 
tion is put into a queue of the system task dis- 
penser indicating that block 2004 should be ex- 
ecuted. 

Block 2004 serves as an interface to transport 
45 software layer 205 and processes messages com- 
ing down, from the transport software layer 205 
either to convert these messages into signaling 
messages to be processed by block 2003 via oval 
2005 or to handle request for facilities or transport 
so capabilities from the higher levels. The primary job 

of INTF MANAGER 2004 is the management of 

facility and transport for a particular interface. In 
order to do this, block 2004 is responsible for 
handling the initial set up of calls, e.g., the call 
55 request and negotiating the number of channels 
necessary for each call. In order to perform this 
function, block 2004 is aware of the number of B 
channels associated with each LDC and chooses a 

21 
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particular B channel or channels to be used for a 
call. It is not the responsibility of block 2004 to 
determine a path through a switching node such as 
switching node 101 or a path through multiple 
switching nodes. Transport layer 205 has the re- 5 
sponsibility for finding that type of a path as is 
described with respect to FIGS. 22, 23, and 24. 
Block 2004 determines by negotiation which B 
channels are used for a particular call. This nego- 
tiation is carried out with another corresponding 10 
entity in the other system element also attempting 
to set up that call, e.g., switching node 102 of FIG. 
5. 

During the set up of a call originated by an 
individual telephone, block 2004 initially negotiates 75 
with the telephone concerning which B channel is 
utilized to transport the voice information and han- 
dles the signaling involved in the Q. 931 protocol. In 
addition, interface manager 2004 sends the appro- 
priate commands down to the link and physical 20 
layers to cause the interface itself to be appro- 
priately set up. 

As the call progresses, transport software layer 
205 determines where the call is going to and sets 
up the internal switching within the node 101. 25 
Transport software layer 205 uses the intra-nodal 
routing routine to accomplish this function. After the 
transport has been arranged through node 101, 
transport software layer 532 invokes block 2004 via 
oval 2008 to negotiate the setup of the call on the 30 
outgoing interface of node 101. Block 2004 per- 
forms this in a similar manner to the negotiation of 
the original setup request from the originating tele- 
phone. In summary, block 2004 is responsible for 
the selection by negotiation which B channels are 35 
used from a particular system interface for a call. 

To better understand the functions of the 
blocks illustrated in FIG. 20, consider the following 
detailed example concerning the setting up of a 
call to switching node 102 from switching node 40 
101. Initially, there would be a request 

(DL DATA IND) primitive coming up from link 

management 530. L3__PROCESSING 2002 is re- 
sponsive to this primitive to check the existence of 
a specific call reference value and to check the 45 
protocol. Block 2002 then places into the queue for - 

L3STA STM 2005 the fact that a message has 

been receive Under control of the system task 
dispenser, oval 2005 initiates the execution of block 
2003 to do the protocol processing on the received so 
message to assure, for example, that the message 
is of the correct state. Block 2003 then indicates to 
the system task dispenser via oval 2008 that there 
is a call request and that block 2004 should be 
executed. Block 2004 then verifies that there is a B 55 
channel available on the requested interface to 
handle this call (if the call requires a B channel) 
and sends back a call proceeding request via oval 



2005. Under control of the system task dispenser, 
oval 2005 initiates block 2003 to generate the call 
proceeding message back to network software lay- 
er 531 in the originating telephone. In addition, 
block 2004 initiates transport software layer 532 via 
oval 2007 to determine that the required resources 
exist within node 101 to complete the call. The 
required resources may be limited to those of 
switching node 101 or may require resources in 
other nodes in order reach the destination node. It 
is the responsibility of transport software layer 532 
and session software layer 533 to determine wheth- 
er the destination node can be reached. Note, 
when block 2003 is invoked to transmit the call 
proceeding message, block 2003 first checks to 
make sure that the transmission of the call pro- 
ceeding message was correct for this stage of the 
call and forms and sends the call proceeding mes- 
sage to L3_PROCESSING 2002. Block 2002 forms 

this message into a dl data req primitive which 

is transmitted to link management 530. 

During the processing of the information by 
transport software layer 532, if transport software 
layer 532 has no information for routing to the 
destination node, transport software layer 532 in 
conjunction with session software layer 533 deter- 
mines the path to the destination node. Session 
software layer 533 determines which node the call 
is destined for by evaluating the dial digits. Once 
session software layer 533 has determined the 
node, transport software layer 532 is responsible 
for determining how to get to that node. After 
determining how to route the call, transport soft- 
ware layer 532 sets up a call to the destination 
node. In order to set up the call to the other node, 
transport software layer 532 invokes 

INTF MANAGER 2004 via oval 2008. Block 2004 

selects an interface that is controlled by the LDC 
and connected to the destination node, and block 
2004 then selects a B channel on that interface. 
After accomplishing this selection, block 2004 ne- 
gotiates the set up of the call with the other node. 
In order to negotiate the set up of the call, block 
2004 invokes the state machine associated with 
oval 2005 to have the proper message generated 
by block 2003 for transmission to the destination 
node. Block 2004 also selects the call reference 
value to be utilized on the LDC. Block 2003 verifies 
that the message can be transmitted (a setup mes- 
sage) and formulates this message and transfers it 
to L3__PROCESSING block 2002. 

The information on paths 2013 and 2014 com- 
prises messages that were received that had a null 
call reference value. These messages fall into two 
general categories. The first category is messages 
which are being transported back and forth be- 
tween layers 533 through 536 with their equivalent 
peers in another node. The second category of 
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messages is those messages that are not call 
related. For example, the button pushes on a sta- 
tion set are not call related and are transmitted 
from the station set to the node with a null call 
reference value. 

Call Routing - Detailed View 

This section describes call routing from the 
prospective of session software layer 533, transport 
software layer 532, and network software layer 531. 
The previous description with respect to FIGS. 20 
and 22 provides greater detail on the actions per- 
formed by network software layer 531 in setting up 
a call. 

FIG. 22 illustrates the manner in which calls are 
identified and processed between network software 
layer 531 , transport software layer 532, and session 
software layer 533. Switching node 101 is execut- 
ing these software layers. At network software layer 
531, each half of a call is identified by the CRN 
number, e.g. CRN 1420, and call record 1421 as 
previously described with respect to FIG. 14. As 
can be seen from FIG. 22, the. call record is com- 
mon throughout the software layers, and each layer 
uses additional information along with the call 
record. The call records are taken from a common 
table within each switching node, and a call record 
number is unique within a particular switching 
node. 

Transport software layer 532 identifies each 
half of a call by the LDCN and call record number. 
The LDCN is utilized because the information illus- 
trated in the level 4 routing tables is identified by 
the LDCN number which denotes the link (or set of 
links) out of a switching node to another switching 
node. Notice that the call record is identified iden- 
tically at all three software layers as illustrated in 
FIG. 22 for a particular call. Session soffware layer 
533 is the point within the software architecture 
where calls are joined together for purposes of 
exchanging signal information by each call having 
a unique session set up for it such as session 
2207. The session record is associated with two 
call records such as call record 1421 and call 
record 1444 with each call record being part of half 
of a call. (Each half of a call is referred to as a 
"half call".) An exception to this rule is if the call is 
to an application. In that case, only one call record 
is utilized since the other half of the call terminates 
at the application software layer. 

To understand how calls are processed by the 
three software layers illustrated in FIG. 22, consider 
the examples given in the following paragraphs. 
For these examples reference must be made to 
FIG. 14 which illustrates the interfaces associated 
with call records 1421 and 1444. Call record 1421 
is associated with PRI link 150, and call record 



1444 is associated with BRI link 144 in the follow- 
ing example. 

Assume that a call is being received on PRI 
link 115 which is destined for BRI station set 124 

5 via BRI link 144. LDCN 1419 was established when 
PRI link 150 became active. When a setup mes- 
sage associated with the call is received via LDCN 
1419, call record 1421 is established and asso- 
ciated with LDCN 1419 as the first half call is being 

w initiated. The destination node number and dialed 
telephone number are transferred from network 
software layer 531 to transport software layer 532. 
Transport software layer 532 determines that 
switching node 101 is the destination node and 

75 sets a node flag which is a flag that records this 
type of information. The node flag and dialed num- 
ber are then communicated to session software 
layer 533. Session software layer 533 determines 
from the dialed number that the call is directed to 

20 BRI station set 124. Session software layer 533 
sets up session record 2207 and establishes call 
record 1444 as being associated with BRI station 
set 124. By establishing these two records, session 
software layer 533 has started the initialization of a 

25 second half call and completed the first half call. 
Session software layer 533 transmits a setup re- 
quest to transport software layer 532 identifying 
that this setup request is associated with LDCN 
1441. The latter LDCN number was established 

30 when BRI link 144 became active. Transport soft- 
ware layer 532 then transmits the setup request to 
network software layer 531 . The latter software 
layer transfers the setup request to BRI station set 
124 via lower software layers and BRI link 144. 

35 Assuming that BRI station set 124 responds with 
an alerting message, this message, is transferred 
up through the second half call which is identified 
by call record 1444 via network software layer 531 
and transport software layer 532 to session soft^ 

40 ware layer 533. The latter software layer utilizes 
information in session record 2207 to identify the 
first half call which is associated with call record 
1421. The alerting message is then communicated 
by transport software layer 532, network software 

45 layer 531, lower software layers, and PRI link 150 
to the originating switching node. 

For a second example, assume that an applica- 
tion in switching node 102 transmits a setup mes- 
sage to establish a logical call with an application 

so in switching node 101. The setup message is pro- 
cessed by setting up the first half call in the same 
manner as was done in the first example. However, 
after session software layer 533 has established 
session record 2207 it does not establish a second 

55 half call but rather transfers the information to the 
application in applications software layer 536. The 
application responds with a connection request 
which is transferred down through software layers 

23 
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533, 532, and 531 after which it is communicated 
to switching node 102 via PRI link 150. 

For the third example, assume that a call is 
being placed from switching node 102 to switching 
node 104 via switching node 101. In addition, as- 
sume for this example that LDCN 1441 is asso- 
ciated with PRI 155 which interconnects switching 
node 104 to switching node 101 as illustrated in 
FIG. 1. Further, assume that the node number 
designates switching node 104. When the setup 
message is received from switching node 102 via 
PRI link 150,. network software layer 531 generates 
a setup indication which is communicated to trans- 
port software layer 532 and establishes call record 
1421 which starts the setting up of the first half 
call. Transport software layer 532 examines the 
node number and determines that switching node 
101 is not the destination switching node; hence, 
layer 532 does not set the node flag. The dialed 
number along with the node flag is communicated 
to session software layer 533 which, because the 
node flag is not set, does not attempt to route a 
call based on the dialed number. Since in the 
present example the node flag is not set, session 
software layer 533 establishes session record 2207 
is established and call record 1444 is selected 
which starts the setting up of the second half call. 
The node and the call record number are then 
communicated to transport software layer 532 as a 
setup request. Transport software layer 532 interro- 
gates the level 4 routing table and* determines that 
LDCN 1441 is a path to switching node 104. Trans- 
port software layer 532 then associates call record 
1444 with LDCN 1441 and transmits the setup 
request to network software layer 531 which then 
establishes communication with switching node 104 
via PRI link 155. Note, as previously discussed in 
FIGS. 6 through 12, it is possible that the node 
number designated switching node 101 as the des- 
tination node but that the dialed number was deter- 
mined by session software layer 533 to exist on 
switching node 104. Whereas different functions 
wouid be performed by software layers 532 and 
533, the two half calls would still be set up as 
previously described and the setup message would 
be routed to switching node 104. 

FIG. 23 illustrates the flow of information being 
received by transport software layer 532 for a half 
call from network software application 531. FIG. 23 
illustrates the actions that are taken by the routines 
at transport software layer 532 in processing each 
unique combination of LDCN and call record such 
as LDCN 1419 and call record 1421 which define a 
half call. Each half call is assumed to be able to 
have three states at transport software layer 532: 
idle state, setup state, and active state. The idle 
state is the initial condition before the call record is 
associated with an LDCN. The setup state occurs 



after the setup indication is received from network 
software layer 531. The active state is entered from 
the setup state after the first end-to-end message 
is received from the other half of the call e.g. 
5 received from session software layer 533. An end- 
to-end message is an alerting, connection, or 
progress message. The software routine illustrated 
in FIG. 23 is responsive to indications received 
from network software layer 531 to either send a 

w request back to network software layer 531 or to 
send indications to seission software layer 533. The 
flow chart of FIG. 23 has two major sections. The 
first section comprises blocks 2302 through 2307 
and is concerned with establishing a new half call 

/5 in response to a setup indication from the network 
software layer. The second section comprises 
blocks 2308 through 2323 and is concerned with 
an established half call. 

Decision block 2301 determines whether or not 

20 the indication being received from network software 
layer 531 is a setup indication. If it is a setup 
indication, decision block 2302 checks to see if the 
call is in the idle state. If the call is not in the idle 
state, error recovery block 2303 is executed since 

25 a setup indication should only be received when 
this half of the call is in the idle state. If the half call 
was in the idle state, block 2304 is executed to 
place this half call in the setup state. Decision 
block 2305 determines whether the node number 

30 of switching node 101 equals the destination node 
number of the setup indication. If the determination 
is yes, the node flag is set. The flag is available to 
both half calls. The node flag is utilized to pass this 
determination to session software layer 533. Blocks 

35 2306 and 2307 are utilized to properly set the node 
flag to indicate whether or not switching node 101 
is the designated node. The setup indication also 
includes the LDCN and call record number from 
network software layer 531 specifying which LDCN 

40 and call record are being utilized. (In this half of the 
call, the LDCN is LDCN 1419 and the call record is 
call record 1421). The call record was selected by 
network software layer 531 when the setup mes- 
sage was received from the physical layer. The 

45 LDCN is determined according to the link on which 
switching node 101 received the setup message. 

With respect to block 2307, it will be recalled 
from the previous discussion with respect to FIG. 4 
that the transport software layer performs all the 

50 necessary routing of a setup message which is not 
designated for the receiving switching node. How- 
ever, it is necessary to transport such a setup 
message to session software layer 533 so that a 
session can be established for this call since the 

55 call is being routed through the receiving switching 
node. Block 2307 accomplishes this purpose. With 
respect to block 2306, it is necessary to pass the 
setup indication to session software layer 533 so 

24 
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that the latter software layer can perform the nec- 
essary actions utilizing the dialed number to deter- 
mine the destination of the call (either an endpoint 
or a subsequent switching node). 

Returning to decision block 2301, if the indica- 5 
tion received from the network software layer was 
not a setup indication, decision block 2318 is ex- 
ecuted to determine whether this half call is in the 
call setup state. If this half call is not in the call 
setup state, then decision block 2319 is utilized to w 
assure that this half call is not in an idle state. The 
idle state indicates an error at this point, and error 
recovery block 2323 would be executed. Assuming 
that this half call is not in the idle state, the 
indication is checked to see whether it is a release 75 
indication. If it is, block 2322 is executed which 
returns the state of the half call back to the idle 
state and releases the call record. In- both cases 
whether or not a release indication is executed, the 
indication is sent to session software layer 533. 20 

Returning to decision block 2318, if the half call 
is in the call setup state, decision block 2313 
checks to see if this is an alerting, connection, or 
progress indication which indicate that the call is to 
go from the call setup state to the active state. 25 
ISDN protocol allows for any three of these mes- 
sages to be given in response to setup message 
under various conditions. If the answer to the deter- 
mination in decision block 2313 is yes, block 2316 
is executed to change the half call to the active 30 
state. Then, block 2315 is executed to utilize the 
information contained in the routing vector of the 
indication (which has been* transferred from the 
network software layer) to update the level 4 rout- 
ing tables. Finally, block 2314 transfers the indica- 35 
tion to session software layer 533. 

Returning to decision block 2313, if the answer 
is no to the determination made by the latter de- 
cision block, decision block 2312 is executed to 
determine whether or not the received message is 40 
a release indication. If it is not a release indication, 
the indication is transferred to the session software 
layer by blocks 2308 and 2309 since it does not 
affect this layer. If it is a release indication, this 
indication is handled in an improved manner in 45 
comparison to prior art telecommunication sys- 
tems. First, the release indication is checked by 
decision block 231 1 to see whether it indicates that 
the call was blocked. If the call was blocked, de- 
cision block 2310 is executed to see whether or not so 
there exists another path to the destination. This 
logic as determined by decision blocks 2311 and 
2310. If block 2310 is executed, an assumption is 
made that a set up message sent to a distant 
switching node has resulted in the distant node 55 
sending a release message. In response to the 
release message, switching node 101 is attempting 
to find another path to the destination switching 



node utilizing the level 4 routing tables as pre- 
viously discussed. If a new path is found by de- 
cision block 2310, control is transferred to decision 
block 2331. The latter block sends a setup request 
to network software layer 531 requesting that the 
latter software layer attempt to establish the call 
utilizing a new LDCN number (which is supplied by 
transport software layer 532) definfng the new path 
using the original session record and call record 
Since the original session record is being utilized, it 
is not necessary for any additional work to be done 
by session software layer 533; hence, no indication 
is transferred to session software layer 533. If ei- 
ther decision block 2311 or 2310 makes a negative 
determination, block 2309 is executed as previous- 
ly described 

FIG. 24 illustrates the actions taken by trans- 
port software layer 532 in response to requests 
being received from session software layer 533. 
FIG. 24 has two main sections. The first section 
comprises blocks 2402 through 2412 and is con- 
cerned with the initial step of setting up a new half 
call. The second section comprises blocks 2415 
through 2426 and is concerned with an established 
half call. An established half call is "either in the 
setup or active state. 

Decision block 2401 checks whether or not the 
state of the half call is in the idle state. If the half 
call is in the idle state, decision block 2402 checks 
to see whether a setup request is being received 
from session software layer 533. If it is not a setup 
request, then block 2403 is executed to perform 
error recovery. If it is a setup request, decision 
block 2404 is executed to check the node flag 
which could have been previously set by transport 
software layer 532 during processing of the other 
half call by either decision block 2306 or 2307 of 
FIG. 23. If the node flag is not set, this indicates 
that the session software layer is setting up a call 
originating on this switching node or that this 
switching node is a tandem point for a previously 
routed call. In this situation, the transport software 
layer must either route the call in a forward, non- 
circular direction or disconnect the call because no 
route is available. To do this, decision block 2405 
determines from the route vector present in the 
message as received from a distant node and the 
level 4 routing tables whether or not a non-circular 
route is available. If there is a non-circular route 
available, block 2406 is executed to send a setup 
request along with a LDCN number to network 
software layer 531. The LDCN identifies the new 
route. In addition, block 2406 sets the state equal 
to the setup state. If a non-circular route is not 
available, block 2407 is executed to send a release 
request to network software layer 531, to set the 
state equal to the idle state, and to inform level 5 to 
remove the session record. 
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Returning to decision block 2404, if the node 
flag indicates that the call was destined for the 
receiving switching node or originated on this 
switching node, block 2408 is executed to find the 
best route to the new destination node. (The best s 
route is determined by the route that has the 
fewest intervening switching nodes). As will be 
described with respect to FIG. 25, session software 
layer 533 is responsive to the node flag indicating 
that switching node 101 is the incoming destination w 
node to change the node number to a new node 
number if the call must be muted to another 
switching node. In such a case, switching node 101 
is an intermediate node in the route to the other 
switching node. Decision block 2409 checks to see 75 
whether or not a route is found. If a route is found, 
decision block 2410 determines whether the route 
found is a circular route. (A circular route is iden- 
tified if either the new destination switching node is 
in the list of switching nodes previously passed 20 
through or if the route selection would return to a . 
previous switching node.) If it is a circular route, 
the redirect request is transmitted to network soft- 
ware layer 531 indicating that the node number has 
been changed and that backing up is the route for 25 
the call. The result is that a redirect message is 
sent to the switching node which transmitted the 
original setup request to switching node 101 since 
it is not necessary to route the call through switch- 
ing node 101. The function of the redirect request 30 
was previously described. If the route is not circular 
as determined by decision block 2410, then block 
241 1 is executed to send the setup request out on 
the new route as defined by the LDCN determined 
in block 2408 to network software layer 531 and to 35 
set the state for this half call to the setup state. 

Returning now to decision block 2401. If the 
determination is no, decision block 2415 is ex- 
ecuted to determine whether this half call is in the 
setup state, If the half call is in the setup state, ao 
decision block 2416 determines whether or not it is 
a release request. If it is a release request, then the 
state of this half call is set to idle. If it is not a 
release request, then decision block 2418 is ex- 
ecuted to determine whether the request is an end- 45 
to-end message. If the answer is yes, then block 
2419 sets the state of this half call to the active 
state, block 2420 makes the B channel connection 
if it was a connect message, and block 2421 sends 
the request to network software layer 531. If the 50 
determination in decision block 2418 was no, then 
block 2421 is immediately executed. 

Returning to decision block 2415. If the deter- 
mination was no, decision blocks 2422 and 2424 
determine whether the request is a setup request 55 
and the half call is in the active state, respectively. 
If the determination made by decision block 2422 
was yes or the determination made by decision 



block 2424 was no, then error recovery block 2423 
is executed. Otherwise, decision block 2425 is ex- 
ecuted to determine whether or not the request is a 
release request. If it is a release request, this half 
call is set to the idle state by 2426 and block 2421 
is executed. 

FIG. 25 illustrates the response of session soft- 
ware layer 533 to indications being received from 
transport software layer 532. Recall from the dis- 
cussion of FIG. 22 that the session software layer 
joins the two half calls to form a complete call 
utilizing a session record. In addition, calls which 
are terminated on an application in the application 
software layer are communicated by the session 
software layer to and from the designated applica- 
tion. In addition, the session software layer is re- 
sponsive to a request coming down from an ap- 
plication to establish a call to an application run- 
ning in another switching node. In addition, the 
session software layer performs routing on the dia- 
led number as previously discussed utilizing the 
level 5 routing tables. FIG. 25 illustrates the opera- 
tion of session software, layer 533 in response to 
indications being received from transport software 
layer 532. Session software layer 533 is responsive 
to these requests to communicate the information 
to an application or to respond by transmitting 
additional requests to transport software layer 532. 
Requests transmitted to transport software layer 

532 can be for either of the two half calls illustrated 
in FIG. 22. With respect to certain indications re- 
ceived from transport, software layer 532, the ses- 
sion software layer 533 simply communicates 
these requests to the other half call. 

Decision block 2501 is responsive to an indica- 
tion received from the transport software layer to 
determine whether or not the indication is a setup 
indication. If the indication is a setup indication, 
decision block 2502 is executed to determine 
whether the node flag indicates that the receiving 
node (switching node 101) is the destination node 
of the indication. Recall that the node flag was set 
by blocks 2306 and 2307 of FIG. 23. If the deter- 
mination in block 2502 is no, session software layer 

533 does not need to perform any routing functions 
since the routing function will be performed on the 
node number which designates the destination 
node. However, a call record is obtained by block 
2503 for the new half call which must be set up. 
For example, assuming that the setup indication 
had been received for the first half call dealing with 
call record 1421 of FIG. 22, the call record to be 
obtained for the second half call would correspond 
to call record 1444 assuming that the call is being 
transported on BRI link 144. After the call record is 
obtained, block 2504 sets up a session record to 
associate the two half calls. Finally, block 2505 
sends the setup request to transport software layer 
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532 so that the latter software layer can perform 
the routing of the setup message based on the 
node number for the second half of the call. 

Returning to decision block 2502, if the answer 
to the determination is yes, decision block 2508 is 5 
executed to determine whether the half call is in- 
tended for an application on switching node 101. If 
the answer is yes, then block 2509 is executed to 
send a connect request back to the other switching 
node concerned with the half call. Note, that a w 
second half call is not set up. However, it is neces- 
sary to set up a session record, and this function is 
performed by block 2510. 

Returning to decision block 2508, if the answer 
to the determination is no, decision block 2513 is 75 
executed. If the answer is yes which means that 
the setup message is for a terminal (such as a BRI 
station set) connected to the switching node, 
blocks 2514 and 2515 are executed to establish a 
new half call, and a setup request is sent to the 20 
terminal by execution of block 2516. 

Returning to decision block 2513, if the termi- 
nal or application is not present on this node it is 
necessary to try to establish a route to the terminal 
by first utilizing the dialed number to determine a 25 
switching node to which that terminal is connected. 
This action is performed by block 2519 as was 
previously described with respect to FIGS. 6 
through 12. Decision block 2520 determines wheth- 
er or not the search for a destination node was 30 
successful. If the search was not successful which 
indicates that switching node 101 cannot identify a 
switching node which hosts the terminal, block 
2521 is executed and. results in a release request 
being sent to transport software layer 532. If a 35 
destination node was found, blocks 2522 and 2523 
are executed to establish a new half call. A setup 
request is sent to transport software layer 532 to 
establish the second half call with the switching 
node that was determined by execution of block 40 
2519. 

Returning to decision block 2501 , if the indica- 
tion is not a setup indication, decision block 2527 
is executed to determine whether it is a release 
indication. If it is a release indication, block 2528 45 
removes the session record which has the effect of 
removing the call. In addition, the release indication 
is sent to transport software layer 532 on the 
second half call. For example, if the release indica- 
tion was received from the half call associated with 50 
call record 1421, block 2529 would transmit the 
release indication to the half call associated with 
call record 1444. As can be envisioned, this opera- 
tion allows the call to be removed through a series 
of switching nodes. ' 55 

Returning to decision block 2527, if the indica- 
tion is not a release indication, decision block 2530 
checks to see if the indication is associated with an 
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application. This check is performed by simply 
examining the session record and communicating 
the information to the destination given in that 
record. Hence, if it is an application, block 2531 is 
executed. However, if it is not an application, the 
information is sent to the second half call by the 
execution of block 2532. 

FIG. 26 illustrates the functions performed by 
the session software layer in response to requests 
being sent from the presentation layer. Decision 
block 2601 determines whether the request is a 
setup request. If it is a setup request, then a half 
call is established at the session software layer by 
execution of blocks 2602 and 2603. Block 2604 
interprets the dialed number which was provided 
by the application to determine the destination 
node. Block 2609 then sends a setup request to 
the transport software layer. 

Returning to decision block 2601, if the request 
is not a setup request, then decision block 2605 
determines whether it is a release request. If it is a 
release request, then block 2606 removes the ses- 
sion record and transfers the release request to 
block 2607 for communication to the transport soft- 
ware layer. Returning to decision block 2605, if the 
answer is no, then block 2608 simply sends the 
request to the transport software layer for commu- 
nication to the terminal or switching node which is 
engaged in a call with the application. 

Before describing in greater detail the actions 
taken by software layers 531, 532, and 533 of FIG. 
22 in implementing the redirect message, consider 
how the redirect message is coded. ISDN signaling 
is defined by the ISDN standard Q.931 and is 
intended to provide an international standard to 
control the initiation of calls, progress of calls, 
termination of calls, communication of national use 
information, local serving network information, and 
user-specific information for telecommunications 
systems and terminals. The redirect message in- 
formation is coded as a vendor type message 
using conventional techniques. For a vendor or 
national type message, the first octet (which de- 
fines the message type) is an escape code which 
causes the switching node to examine the second 
octel to determine if the message is a national or 
vendor-type message. 

To understand how these software layers re- 
spond to the redirect message, consider the exam- 
ple where a telephone call is being set up between 
BRI station set 126 and BRI station set 123 using 
only node and dialing plan hierarchical information. 
Recall that the setup message is initially routed 
from BRI station set 126 to switching node 102 via 
switching nodes 109, 104, and 101. When the 
setup message is routed to switching node 102 
from switching node 101, the latter switching node 
determines that the call path needs to be set up 
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back through from switching node 101. Switching 
node 102 utilizes the redirect message to remove 
the call path between switching node 102 and 
switching node 101 and to inform switching node 
101 to determine another path. The redirect mes- 
sage sent by switching node 102 specifies that the 
node number has changed and specifies that this 
new switching node number is the node number for 
switching node 101. Switching node 101 is respon- 
sive to the redirect message to interrogate its level 
5 routing table with the telephone number of BRI 
station set 123 and to determine that a setup 
message should be sent to switching node 111. 

Consider the operation performed by switching 
node 102 with respect to FIG. 22. As the setup 
message is received, it progresses up through soft- 
ware layers 531, 532, and 533 along the left call 
leg of the call (call record 1421 and LDCN 1419). 
When the setup message is received by* session 
software layer 533, it interrogates the level five 
routing tables and determines that the destination 
switching node is switching node 101. Session 
software layer 533 then transmits a setup request 
to transport software layer 532 along the right call 
leg of FIG. 22 (caW record 1444 and LDCN 1441). 
However, when transport software layer 532 re- 
ceives the setup request from session software 
layer 533, transport software layer 532 determines 
that a circular subpath would be set up between 
switching node 102 and 101. Consequently, trans- 
port software layer 532 transmits a redirect indica- 
tion back to session software layer 532. Session 
software layer 533 is responsive to the redirect 
indication to remove session record 2207 and to 
send a redirect request to transport software layer 
532 on the left call leg of FIG. 22. In turn, transport 
software layer 532 sends a redirect request to 
network software layer 531. The redirect request 
causes network software layer 531 to remove call 
record 1421, LDCN 1419, and CRN 1420 and to 
totally remove all lower protocols associated with 
this particular call. Also, network software layer 531 
sends a redirect message to switching node 101: 

Examine the operations, with respect to FIG. 
22, performed by switching node 101 in response 
to the redirect message received from switching 
node 102. Switching node 101 had initially received 
a setup message from switching node 104, and this 
setup message set up the left call leg illustrated in 
FIG. 22 (call record 1421 and LDCN 1419 with 
session record 2207 controlling both legs). In re- 
sponse to this setup message, session software 
layer 533 transmits a setup request to transport 
software layer 532 via the right call leg of FIG. 22 
to switching node 102. When switching node 102 
transmits the redirect message back to switching 
node 102, the redirect message is received on the 
right call leg of FIG. 22. Software layers 533, 532, 



and 531 must remove the call that had been at- 
tempted to be established to switching node 102; 
however, call record 1444 and session record 2207 
are preserved for use in the path that will be 

5 established between switching node 101 and 
switching node 111. In response to redirect mes- 
sage, network software layer 531 and lower layers 
remove the call to switching node 102 just as if a 
release message had been received from switching 

70 node 102. In response to the redirect indication, 
session software layer 533 determines that the call 
should be connected to switching node 111 and 
transmits a setup message to transport software 
layer 532 requesting that call be setup to switching 

75 node 111. Transport software layer 532 is respon- 
sive to the setup request received from session 
software layer 532 to select a new call record and 
a new LDCN (which are still denoted as call record 
1444 and LDCN 1441 in FIG. 22) and to transmit 

20 the setup request to network software layer 531 via 
the right call leg of FIG. 22. 

Consider now in greater detail how the redirect 
message is processed by session software layer 
533 and transport software layer 532 in FIGS. 23 

25 through 25. Consider first how switching node 102 
responds to the setup message from switching 
node 101 to transmit a redirect message back to 
switching node 101. The setup message _is re- 
ceived in the left call leg of FIG. 22. The setup 

30 message is received by network software layer 531 
in switching node 102, and a setup indication is 
transmitted up to transport software layer 532 as 
was previously discussed. When transport software 
layer 532 receives the setup indication, it pro- 

35 cesses this indication as indicated in FIG. 23 . by 
executing blocks 2301. 2302, 2304, and 2305 as 
was previously described. Since the node number 
indicates that the destination switching node is 
switching node 102, block 2306 is executed to set 

40 the node flag to indicate that the designation num- 
ber equals the present node number after the de- 
cision is made by decision block 2305. Transport 
software layer 532 then sends a setup indication to 
software layer 533. 

45 Session software layer 533 of switching node 

102 processes the setup indication as illustrated in 
FIG. 25 by executing decision blocks 2501 and 
2502. Since the node flag was set to indicate that 
the present node number equals the destination 

so node number, decision blocks 2508 and 2513 are 
executed with the determinations being "no" in 
both cases resulting in block 2519 being executed. 
Upon block 2519 being executed, the session soft- 
ware layer 533 of switching node 102 determines 

55 that the block of numbers containing the telephone 
number of BRI station set 123 had been given to 
switching node 101. Decision block 2520 deter- 
mines that a designation node was found in block 
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2519 and causes blocks 2522, 2523, and 2524 to 
be executed which result in a call record and a 
setup session record being obtained and a setup 
request being transmitted in the right hand call leg 
of FIG. 22 to transport software layer 532 of switch- 
ing node 102. 

This setup request is processed by transport 
software layer 532 in accordance with FIG. 24. 
Decision blocks 2401, 2402, and 2404 are ex- 
ecuted with "yes" determinations resulting. Since 
the answer to the determination posed by decision 
block 2404 is "yes", block 2408 is executed result- 
ing in a path being determined to switching node 
101 via PRI link 150. Consequently, the answer to 
decision block 2409 is "yes", and the answer to 
decision block 2410 is "yes" since the route is 
circular resulting in block 2412 being executed. 
The execution of block 2412 results in a redirect 
indication being communicated to session software 
layer 533 along the right call leg of FIG. 22 and the 
node flag being set equal to the destination number 
not equaling the present node number. In this 
situation of a redirect indication being communi- 
cated to session software layer 533 along the right 
call leg, the node flag is utilized to indicate to the 
session software layer 533 that transport software 
layer 532 had determined a circular subpath. 

At session software layer 533, the redirect in- 
dication is processed as illustrated in FIG. 25. 
Decision blocks 2501, 2527, and 2530 produce 
"no" determinations resulting in decision block 
2533 being executed. Decision block 2533 deter- 
mines whether the indication from the transport 
software layer was a redirect indication. Hence, the 
determination made by decision block 2533 is 
"yes". In response to this "yes" determination, 
decision block 2541 is executed resulting in the 
execution of block 2542 since the node flag is set 
to indicate that the destination node number does 
not equal the present node number. Execution of 
block 2542 results in a redirect request being com- 
municated to transport software layer 532 for the 
left call leg of FIG. 22. Session software layer 533 
removes session record 2207, and the redirect 
request specifies that the destination number is to 
be the node number of switching node 101. As will 
be described shortly, this results in a redirect mes- 
sage being sent back to switching node 101. 

Transport software layer 532 is responsive to 
the redirect request to process this request as 
illustrated in FIG. 24. The determination made by 
decision block 2401 is "no" resulting in the execu- 
tion of decision block 2423. Since it is a redirect 
request, decision block 2428 transfers control to 
block 2429 which transmits a redirect request to 
network software layer 531 along the left call leg of 
FIG. 22. Network software layer then transmits a 
redirect message to switching node 101. As the 



redirect request is processed by network software 
layer 531 and lower software layers, these software 
layers respond to the redirect request to clear the 
call with switching node 101 as if the redirect 

5 request was a release request. 

Consider now how switching node 101 re- 
sponds to the redirect message received from 
switching node 102. Network software layer 531 in 
switching node 101 is responsive to the redirect 

10 message to remove the lower level portions of the 
call including LDCN and call record along the right 
call leg of FIG. 22 and to transmit a redirect indica- 
tion to transport layer 532 which is processed as 
indicated in FIG. 23. Upon execution of decision 

75 block 2301, control is transferred to decision block 
2318 since the indication is not a setup indication. 
Since the call had previously been put in the setup 
state, control is transferred from decision block 
2318 to decision block 2313. The latter decision 

20 block transfers control to decision block 2312 
which in turn transfers control to decision block 
2323. Since the indication is a redirect indication, 
control is transferred to decision block 2324 by 
decision block 2323. Decision block 2324 makes 

25 the decision of whether or not the redirect message 
is a redirect from a switching- node to alter routing 
or is a redirect from a BRI station set to implement 
a feature such as send alt calls. Such a feature is 
described in our copending application entitled 

30 "Redirection of Calls by a Communication Termi- 
nal" filed on the same day as the present applica- 
tion and assigned to the same assignee. This de- 
cision is based on whether or not a destination 
node number is present in the redirect message. If 

35 a destination node number, is present in the re- 
direct message, this means that the message is 
from a switching node and is to effect the routing 
of a call. However, if there is no destination node 
number present in the redirect message, this is 

40 interpreted as being from BRI station set or some 
other communication terminal. In the present situ- 
ation, there is a destination node number present 
which is the node number of switching node 101. 
Therefore, control is passed from decision block 

45 2324 to decision block 2325. Since the destination 
number is equal to the present node number, con- 
trol is passed from decision block 2325. to block 
2329. As will be seen shortly, the path starting at 
block 2329 is one in which the session software 

so layer will look at the dialed telephone number to 
determine a route. 

Returning momentarily to decision block 2325, 
if the answer to this determination was "no" in- 
dicating that routing was to be to another switching 

55 node, block 2326 obtains a new call record for the 
right call leg of FIG. 22 and transfers control to 
block 2408 of FIG. 24 so that a route can be 
determined to this new destination switching node. 
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Returning now to block 2329, the latter block sets 
the node flag to indicate that the destination node 
number is equal to the present node number and 
executes block 2330 which sends a redirect indica- 
tion to session software layer 533. 

Session software layer 533 of switching node 
101 is responsive to the redirect indication from the 
transport software layer to process this indication 
as illustrated in FIG. 25. In FIG. 25, decisions 
blocks 2501, 2527, and 2530 are executed result- 
ing in "no" determinations and execution of de- 
cision block 2533. Since the indication is a redirect 
indication, the execution of decision block 2533 
results in decision block 2541 being executed. 
Since the node flag does indicate that the present 
node number is the destination node number, de- 
cision block 2543 is executed. Note, if the deter- 
mination in decision block 2541 was "no" block 
2542 would have been executed which would have 
resulted in a setup request for a different switching 
node than switching node 101 being transmitted to 
the transport software layer using the same session 
record that had been utilized when attempting to 
set up a call path to switching node 102. Returning 
now to decision block 2543. Since the destination 
terminal is not connected to switching node 101, 
block 2545 is executed rather than block 2544. 
Block 2545 searches the level five routing table 
utilizing the telephone number of the destination 
terminal. This search results in the switching node 
number being determined to be that of switching 
node 111. Since a switching node was found, de- 
cision block 2546 results in block 2548 being ex- 
ecuted which transmits a setup request down to 
transport software layer 532 of switching node 101. 
The setup request uses the same session record 
as was utilized when a call was attempted to be set 
up to switching node 102, but a new call record is 
obtained. 

Transport software layer 532 of switching node 
101 is responsive to the setup request from the 
session software layer to process this request as 
illustrated in FIG. 24 and as previously described. 

Internal Configuration Identification 

At initialization time, each component of a 
switching module runs internal diagnostics on itself 
and then transfers its identification and results of 
the internal diagnostics to the angel processor con- 
trolling the module. As illustrated in FIG: 5, there 
are two types of modules. A remote module, such 
as remote module 511, is physically remoted from 
node processor 510 via a BRI or PR.I link. A local 
module (such as one comprising local angel 512, 
network 515, interface 516, and interface 517) is 
physically located in the same board carrier with a 
node processor (such as node processor 51.0) with 



the node processor implementing the local angel in 
software. The process of doing internal configura- 
tion identification is described with respect to re- 
mote module 51 1 ; however, a local module per- 
5 forms similar operations. 

A front view of remote module 51 1 is illustrated 
in FIG. 27 and a back view is illustrated in FIG. 28. 
As illustrated in FIG 27, remote module 51 1 com- 
prises printed circuit boards 2701 through 2706 

w which are physically mounted in board carrier 
2707. These boards plug in to backplane 2008, as 
illustrated in FIG. 28, which is attached to carrier 
2707. Each of the boards illustrated in FIG. 27 has 
a processor for running initial diagnostics on the 

75 circuits of that board and also for reporting the 
identification of the board to the remote angel 
processor 520 which is physically mounted on re- 
mote angel processor board 2706. 
- in addition, as illustrated in FIG. 28, backplane 

20 2801 has physically mounted on it backplane pro- 
cessor 2002. Backplane processor 2002 provides 
information denoting the backplane type of back- 
plane 2001, the number of boards plugged into 
backplane 2001 , and the location of each board. 

25 Network 529 of FIG. 5 is physically imple- 

mented by network board 2704, and Jnterface 527 
of FIG. 5 is implemented on PRI board 2702. 
Auxiliary circuits are mounted on tone board 2705. 
Power board 2701 provides the necessary power to 

30 the boards plugged into backplane 2801. Power 
supply 2708 supplies power to power board 2701. 
A local module consists of boards similar to those 
illustrated in FIG. 27 with the exception that a node 
processor board replaces angel processor board 

35 2706. 

FIG. 29 illustrates, in block diagram form, re- 
mote module 511. All of the processors illustrated 
in FIG. 29 communicate with each other via pro- 
cessor bus 2913. When remote module 511 is first 

40 initialized, power processor 2002 determines 
whether power supply 2001 is operational and the 
type of power supply as to voltages and output 
power. Power processor 2002 then transfers this 
information to remote angel processor 520. Simi- 

45 iarly, tone processor 2904 performs diagnostics on 
tone circuit 2903 to ascertain whether this circuit is 
fully operational. Tone processor 2904 then reports 
the results of its diagnostics and the tone board 
type of tone board 2705 to remote angel processor 

so 520 via processor bus 2913. Backplane processor 
2802 determines the number and location of 
boards plugged into backplane 2801 of FIG. 28 and 
transmits this information to remote angel proces- 
sor 520 via processor bus 2913. Network processor 

55 2909 performs diagnostics and identifies the fabric 
type of switch fabric 2908 to remote angel proces- 
sor 520. Switch fabric 2908 can be a variety of 
different types of switching technology, i.e. optical 

30 
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switching for broadband communications. Control 
processors 2907 and 2910 perform diagnostics on 
their respective boards and report the results of 
these diagnostics and the type of board along with 
the number of interface circuits to remote angel 
processor 520 via processor bus 2913. 

After all of the information has been reported to 
remote angel processor 520, the latter processor 
transmits this information to node processor 510 
via switch fabric 2908 and BRI interface 2911. 
Angel processor 520 communicates information 
with BRI interface 2911 via processor bus 2-913 
and control processor 291 1 . The manner in which 
node processor 510 is interconnected to remote 
module 511 by a BRI link is discussed in our U.S. 
patent application, Serial No. 07/636,528, of B. M. 
Bales et aL 5-1-2-1, filed December 31, 1990, en- 
titled "Transport Remotrng of Switch Network Con- 
trol Over a Standard Interface Link", having the' 
same inventors and assignee as the present ap- 
plication. 

Redirection of Calls by a Station Set 

To understand how a redirect operation is han- 
dled by a switching node when the redirect mes- 
sage is from a station set implementing a feature 
such as send all calls, consider the following exam- 
ple. Assume that BRI station set 124 places a call 
to BRI station set 123. BRI station set 123 has 
been activated to implement the send all calls 
feature and to transfer such calls to BRI station set 

122. When the setup message from switching node 
101 is received by switching node 111, the left call 
leg, as illustrated in FIG. 22 is setup in switching 
node 111. Switching node 111 attempts by trans- 
mission of a setup message to set up the right call 
leg, as illustrated in FIG. 22, with BRI station set 

123. In response to the setup message, BRI station 
set 123 transmits a redirect message back to 
switching node 111 indicating that the telephone 
number has been changed. As was previously de- 
scribed, this indication is made by not including a 
designation node number in the redirect message. 
BRI station set 123 changes the designation station 
number to that of BRI station set 122 in the redirect 
message. 

In response to the redirect message, switching 
node 1 1 1 removes the right call leg as illustrated in 
FIG. 22, determines a path for the call based on 
the telephone number of BRI station set 122, sets 
up the right leg of call, and communicates a setup 
message along this path towards BRI station set 
122. The details on how the transport and session 
software layers of switching node 1 1 1 process this 
redirect message have already been discussed in 
the discussion of how switching node 101 pro- 
cessed the redirect message from switching node 



102 with respect to FIGS. 22 through 25. 

Consider the redirect operation from the point 
of view of BRI station set 123. BRI station set 123 
is illustrated in greater detail in FIG. 30. BRI station 
5 set 123 is controlled by microprocessor 3001 and 
comprises BRI interface 3003, display 3004, mem- 
ory 3002, keyboard 3005, and handset 3006. Dis- 
play 3004 and keyboard 3005 can* either be phys- 
ically realized as a digital terminal like interface or 

w as a display telephone set such as illustrated in 
U.S. Patent No. 4,790,004. 

Microprocessor 3001 implements the software 
structure illustrated in FIG. 31 with software layers 
3103 through 3104 performing similar functions as 

75 the corresponding software layers in FIG. 4. How- 
ever, the transport and session layers are not im- 
plemented as completely as on a switching node 
since no routing is being performed. The physical 
layer is performed by BRI interface 3003. BRI 

20 interface 3003 is responsive to control signals from 
microprocessor 3001 to perform the initialization 
previously described and also to direct voice calls 
received on either of the B channels of BRI link 
138 to handset 3006. 

25 When the setup message is first received from 

switching node 111, network * software layer 3104 
determines whether there are sufficient facilities to 
handle the call. If a B channel is required, the 
manner in which the B channel is determined and 

30 negotiated with switching node 1 1 1 has already 
been described. If the facilities are available, a 
setup indication is muted up through the software 
layers to applications software layer 3109 to termi- 
nal management application 3101. The latter ap- 

35 plication determines if the call is to be transferred 
and determines the telephone number to which the 
call is being transferred. If the call is being trans- 
ferred, terminal management application .3101 
transmits down a redirect request including the 

40 new designation telephone number to the lower 
software layers. This redirect request is then 
passed down through the various software layers in 
a manner similar to the left call leg of FIG. 22 
removing any call facilities that had been assigned. 

45 The redirect message is then transmitted back to 
switching node 111 which performs the previously 
defined operations. 

FIG. 32 illustrates in greater detail the oper- 
ations performed by terminal management 3101 in 

so response to a setup indication. The data which is 
stored in memory 3002 defining the actions to be 
performed and the telephone numbers to be used 
in FIG. 32 are stored in memory 3002 by micropro- 
cessor 3001 executing local operations application 

55 3102 which allows the user via display 3004 and 
keyboard 3005 enter the necessary data. In re- 
sponse to the setup indication, decision block 3001 
determines whether or not the call is to be a voice 
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call. If the determination is "yes" control is passed 
to decision block 3207 which determines whether 
or not voice calls are being transferred. If voice 
calls are not being transferred, control is trans- 
ferred to block 3209 which handles the call in a 
normal manner. If voice calls are being transferred, 
control is passed to decision block 3208 which 
determines whether special features are being in- 
voked. If no special features are being invoked 
which indicates the operations of a send all calls 
feature, decision block 3210 is executed to access 
the telephone number to which the call is to be 
transferred to from memory 3002, and then, block 
321 1 is executed to send a redirect indication 
which specifies no switching node number and 
includes the telephone number obtained by block 
3210. The redirect indication is received by session 
layer 3106 which removes the session record and 
then transfers the redirection indication to transport 
layer 3105. Software layers 3105 through 3103 
respond to the redirect indication as was previously 
described for a switching node. 

Returning to decision block 3208, if the special 
features are invoked, control is passed to decision 
block 3212. Decision block 3212 interrogates the 
location of the calling party. If the calling party is 
outside of the telecommunications switching sys- 
tem illustrated in FIG. 1, then the call will be 
transferred to a different station set than if the 
calling party was inside the telecommunications 
system illustrated in FIG. 1. For example, if it is an 
inside call the calling party is transferred to a voice 
mail system; but, on the other hand, if it is an 
outside call, the calling party is transferred to a 
station set manned by a person. If the determina- 
tion in decision block 3212 is "yes", blocks 3213 
and 3214 are executed. However, if the determina- 
tion of decision block 3212 is "no", control is 
transferred to blocks 3215 and 3216. 

Returning to decision block 3201, if the deter- 
mination was "no", control is transferred to de- 
cision block 3202. As previously described, de- 
cision block 3202 examines the bearer capability IE 
information to determine if the call is a data call or 
not. If the call is not a data call, control is trans- 
ferred to block 3206 which processes this call in 
the normal manner. However, if it is a data call, 
control is transferred to decision block 3203 which 
examines the higher layer capability IE information 
of the setup indication to determine whether or not 
the call is a fax call. If it is a fax call, control is 
transferred to block 3204 which accesses the num- 
ber assigned to fax 146 of FIG. 1. A redirect 
indication is then formed utilizing this access num- 
ber and is transmitted to session layer 3106 as was 
previously described. Next, block 3217 is executed 
to send an indication to display 3004 of FIG. 30 to 
indicate that a fax message had been received and 



sent to fax machine 146. If the display is of the 
type described in U.S. Patent No. 4,790,004 the 
indication will turn on an indicator light. 

Returning to decision block 3203, if the deter- 

5 mination is "no" control is transferred to block 
3205 which accesses from memory 3002 the tele- 
phone number utilized by computer 149 of FIG. 1. 
A redirect indication is formed utilizing this tele- 
phone number and sent to session layer 3106. 

w Finally, block 3218 is executed which sends an 
indication to display 3004 to indicate that a mes- 
sage has been transferred to computer 149 of FIG. 
1. 

75 Claims 

1. A method for routing a call from a first tele- 
phone station set to a second telephone station 
set where the telephone station sets are con- 

20 nected to a telecommunication switching sys- 

tem having a plurality of switching nodes inter- 
connected by links and the telephone station 
sets each being identified by an unique tele- 
phone number, comprising the steps of: 

25 receiving a setup message of a call by the 

first telephone station set from a switching 
node; 

transmitting a message to redirect the call 
to a second telephone station set where the 

30 redirect message comprises the telephone 

number of the second telephone station set 
and information that the telephone number has 
been changed whereby the switching node is 
responsive to the redirect message to route 

35 the call to the second telephone station set. 

2. The method of claim 1 further comprises the 
steps of searching internal routing tables by 
the switching node to find the route to the 

40 second telephone station set; and 

routing the call to the second telephone 
station set in response to a route being found. 

3. The method of claim 2 wherein the redirect 
45 message is a ISDN protocol message and the 

step of transmitting comprises the step of for- 
ming special type message that defines the 
redirect message. 

so 4. The method of claim 3 wherein the special 
type message is a vendor type. 

5. An apparatus for routing a call from a first 
telephone station set to a second telephone 
55 station set where the telephone station sets are 

connected to a telecommunication switching 
system having a plurality of switching nodes 
and the telephone station sets each being 
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identified by an unique telephone number, 
comprising: 

means in the first telephone station set for 
receiving a setup message of a call from a 
switching node; 5 

means in the first telephone station set for 
transmitting a redirect message to the switch- 
ing node to transfer the call to the second 
telephone station set where the redirect mes- 
sage comprises the telephone number of the w 
second telephone station set and information 
that the telephone number has been changed 
whereby the switching node is responsive to 
the redirect message to route the call to the 
second telephone station set. 15 

6. The apparatus of claim 5 the switching node 
further comprises means for searching internal 
routing tables to find the route to the second 
telephone station set; and 20 

means for routing the call to the second 
telephone station set in response to a route 
being found. 

7. The apparatus of claim 6 wherein the redirect 25 
message is a special ISDN protocol type mes- 
sage. 

8. The apparatus of claim 7 wherein the special 
ISDN protocol type message is a vendor type 30 
message. 
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